X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 474359FA278 for ; Wed, 24 May 2006 17:18:46 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 28530-10 for ; Wed, 24 May 2006 17:18:35 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id A89C89F9398 for ; Wed, 24 May 2006 17:18:35 -0300 (ADT) Received: mir3-fs.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes.mirlogic.com by mir3-fs.mir3.com; 24 May 2006 13:18:33 -0700 Subject: Re: Getting even more insert performance (250m+rows/day) From: Mark Lewis To: "Daniel J. Luke" Cc: Dave Dutcher , pgsql-performance@postgresql.org In-Reply-To: References: <01f701c67f6d$0578bf40$8300a8c0@tridecap.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Wed, 24 May 2006 13:18:32 -0700 Message-Id: <1148501913.28095.70.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/452 X-Sequence-Number: 19239 > The data gets inserted in batches every 5 minutes and I potentially > have people querying it constantly, so I can't remove and re-create > the index. How live does your data need to be? One possibility would be to use a separate table for each batch instead of a separate table per day, create the indexes after the import and only after the indexes have been created make the table available for user queries. You'd be trading latency for throughput in that case. Also, you mentioned that you're CPU-bound, but that you have multiple CPU's. In that case, performing N concurrent imports (where N is the number of processor cores available) might be a win over a single- threaded import. -- Mark Lewis