Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UDTkz-0006zj-0F for pgsql-performance@arkaria.postgresql.org; Thu, 07 Mar 2013 05:52:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UDTkx-0000fM-V9 for pgsql-performance@arkaria.postgresql.org; Thu, 07 Mar 2013 05:52:44 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UDTkw-0000fG-U0 for pgsql-performance@postgresql.org; Thu, 07 Mar 2013 05:52:43 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UDTku-0002TC-EP for pgsql-performance@postgresql.org; Thu, 07 Mar 2013 05:52:42 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r275qaBE021701; Thu, 7 Mar 2013 00:52:36 -0500 (EST) From: Tom Lane To: Josh Berkus cc: pgsql-performance@postgresql.org Subject: Re: Poor plan when joining against a union containing a join In-reply-to: <5137CDFC.1060902@agliodbs.com> References: <5137CDFC.1060902@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Wed, 06 Mar 2013 15:15:08 -0800" Date: Thu, 07 Mar 2013 00:52:35 -0500 Message-ID: <21700.1362635555@sss.pgh.pa.us> X-Pg-Spam-Score: -2.5 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Josh Berkus writes: > On 03/06/2013 06:54 AM, David Leverton wrote: >> I'm encountering very poor query plans when joining against a union, > Actually, in case #4, Postgres *is* pushing down the join qual into the > segments of the Union. Yeah, but not further. I believe the core issue here (as of 9.2) is that we're not willing to generate parameterized paths for subquery relations. We could do that without a huge amount of new code, I think, but the scary thing is how much time it might take to generate (and then discard most of the) plans for assorted parameterizations of complicated subqueries. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance