From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nate Allan <nallan@ancestry.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Terrible plan for join to nested union
Date: Mon, 09 Jul 2012 01:49:52 -0400
Message-ID: <29374.1341812992@sss.pgh.pa.us> (raw)
In-Reply-To: <9B2D6747F4AB8A47BE45216B06DEDAF92ABE6739@PREXMB01.myfamily.int>
References: <9B2D6747F4AB8A47BE45216B06DEDAF92ABE667B@PREXMB01.myfamily.int>
<19124.1341706090@sss.pgh.pa.us>
<9B2D6747F4AB8A47BE45216B06DEDAF92ABE66BC@PREXMB01.myfamily.int>
<3857.1341762995@sss.pgh.pa.us>
<9B2D6747F4AB8A47BE45216B06DEDAF92ABE6739@PREXMB01.myfamily.int>
Nate Allan <nallan@ancestry.com> writes:
> 2) Why would more effort go into Union All rather than Union?
The UNION ALL case matches up with, and shares planning and execution
code with, table-inheritance and partitioning scenarios. So yes, it
really is more interesting to more people than UNION DISTINCT.
(IIRC, the code that does that stuff was originally meant to support the
inheritance case, and we hacked UNION ALL to be able to share the logic,
not vice versa.)
Right now, UNION DISTINCT, along with INTERSECT and EXCEPT, have
basically no optimization support whatsoever: all of them go through a
code path that just evaluates both input relations and performs the
set-combination operation. All of that code dates from a period about
a dozen years ago when we were more interested in getting the right
answer at all than how fast it was. Rewriting it all to have some
optimization capability is certainly on the wish-list ... but the fact
that it hasn't risen to the top of anybody's to-do list in that time
indicates to me that it probably isn't going to get done in the next
little while either. And even if someone were to start working on it
right now, it's not a small project.
Sorry to be the bearer of bad news, but this isn't going to change
just because you try to label it a bug.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, nallan@ancestry.com
Subject: Re: Terrible plan for join to nested union
In-Reply-To: <29374.1341812992@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox