X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id EE6FB3ABC89 for ; Wed, 22 Dec 2004 01:40:28 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 76238-09 for ; Wed, 22 Dec 2004 01:40:19 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by svr1.postgresql.org (Postfix) with ESMTP id 7FC4E3A60CD for ; Wed, 22 Dec 2004 01:40:20 +0000 (GMT) Received: from grownups (c-24-21-166-228.client.comcast.net[24.21.166.228]) by comcast.net (sccrmhc13) with SMTP id <20041222014019016003g6gle>; Wed, 22 Dec 2004 01:40:19 +0000 Message-ID: <006901c4e7c7$62118500$0200a8c0@grownups> From: "Stacy White" To: "Josh Berkus" , "Greg Stark" Cc: References: <000a01c4da74$84e072e0$0200a8c0@grownups><200412151025.02262.josh@agliodbs.com><87oegvqrst.fsf@stark.xeocode.com><200412151156.40908.josh@agliodbs.com> <87vfb3p40w.fsf@stark.xeocode.com> Subject: Re: Partitioned table performance Date: Tue, 21 Dec 2004 17:41:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.24 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE X-Spam-Level: X-Archive-Number: 200412/269 X-Sequence-Number: 9644 The discussion seems to have diverged a little, so I don't feel too bad about making some semi-off-topic comments. From: "Greg Stark" > Like I said though, we found "global indexes" defeated the whole purpose. First semi-off-topic comment: I think this depends on the index, the data, and the goal of the partitioning. We use partitioning on one of our Oracle projects for performance rather than managability. In this case, a global index on a non-partitioned field can be helpful. Imagine an 'orders' table with 100 partitions on week. Products have a short life cycle, and are typically around for only a week or two. A query like 'SELECT * FROM orders WHERE product_no = ?' forces a lookup on 100 different local indexes, but only one global index. Second-semi-off-topic comment: Josh mentioned that Oracle's partitioning introduces it's own overhead, so I re-ran my earlier benchmarks on one of our Oracle machines. I believe Oracle's licensing agreement prohibits me from posting any benchmarks, so all I'll say is that Postgres' inheritance partitioning implementation is _very_ low overhead, and even union views are competitive.