Re: Using indices for UNION. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Using indices for UNION.
Date
Msg-id 20807.1396631678@sss.pgh.pa.us
Whole thread Raw
In response to Re: Using indices for UNION.  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Using indices for UNION.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-01-14 18:10:40 +0900, Kyotaro HORIGUCHI wrote:
>> This patch flattens UNION likewise currently did for UNION ALL.

> I haven't really followed this topic, so please excuse my ignorance.

> This is still marked as "needs review" in
> https://commitfest.postgresql.org/action/patch_view?id=1374 . But I am
> not sure the patch as is is relevant after
> a87c729153e372f3731689a7be007bc2b53f1410?

I think it's an independent issue.

After a quick read of the patch (which is really badly explained :-()
I think the idea is that a nest of UNIONs with no datatype conversions
can be flattened into a UNION ALL appendrel, with the required duplicate
elimination handled by sticking a DISTINCT onto the top level.

However, it's not clear to me that this is worth the trouble.  The
DISTINCT would act as an optimization fence preventing the subquery from
being flattened any further, so it doesn't seem like there would be any
global benefit just because it now contains a simple appendrel rather than
a setop tree.  And a nest of conversion-free UNIONs already results in a
plan that's a flat Append followed by sort/uniq, which seems like the same
thing you'd get from the DISTINCT.  So what's the point?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Joshua Yanovski
Date:
Subject: Re: Proposal: COUNT(*) (and related) speedup
Next
From: Tom Lane
Date:
Subject: Re: Proposal: COUNT(*) (and related) speedup