Re: Using indices for UNION.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Using indices for UNION.
Дата
Msg-id 20807.1396631678@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Using indices for UNION.  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Using indices for UNION.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Joshua Yanovski
Дата:
Сообщение: Re: Proposal: COUNT(*) (and related) speedup
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Proposal: COUNT(*) (and related) speedup