Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id F02441337BEE for ; Thu, 7 Oct 2010 10:53:05 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 99456-06 for ; Thu, 7 Oct 2010 13:52:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 0096B1337B47 for ; Thu, 7 Oct 2010 10:52:57 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o97DqnWn027854; Thu, 7 Oct 2010 09:52:49 -0400 (EDT) To: Heikki Linnakangas cc: Simon Riggs , Vincenzo Romano , pgsql-hackers@postgresql.org Subject: Re: On Scalability In-reply-to: <4CAD7BED.4050009@enterprisedb.com> References: <1280423526.8613.36.camel@jd-desktop.unknown.charter.com> <1280425184.8613.41.camel@jd-desktop.unknown.charter.com> <1280427410.8613.44.camel@jd-desktop.unknown.charter.com> <4CAD769D.9090301@enterprisedb.com> <1286437290.2304.192.camel@ebony> <4CAD7BED.4050009@enterprisedb.com> Comments: In-reply-to Heikki Linnakangas message dated "Thu, 07 Oct 2010 10:51:09 +0300" Date: Thu, 07 Oct 2010 09:52:49 -0400 Message-ID: <27853.1286459569@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201010/452 X-Sequence-Number: 171492 Heikki Linnakangas writes: > On 07.10.2010 10:41, Simon Riggs wrote: >> Constraint exclusion is linear with respect to number of partitions. >> Why do you say exponential? > For some reason I thought the planner needs to check the constraints of > the partitions against each other, but you're right, clearly that's not > the case. Linear it is. Well, it's really more like O(mn) where m is the number of partitions and n is the number of clauses in the query --- and not only that, but the O() notation is hiding a depressingly high constant factor. And then there are practical problems like failing to exclude partitions as soon as there are any parameters in the query. There's basically no way that we're going to get decent performance for large numbers of partitions as long as we have to resort to theorem-proving to lead us to the correct partition. regards, tom lane