Re: Optimisation of INTERSECT expressions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Optimisation of INTERSECT expressions
Дата
Msg-id 21623.1080062491@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Optimisation of INTERSECT expressions  (Bruno Wolff III <bruno@wolff.to>)
Список pgsql-performance
Bruno Wolff III <bruno@wolff.to> writes:
> On Tue, Mar 23, 2004 at 11:21:39 -0500,
>   Phil Endecott <spam_from_postgresql_lists@chezphil.org> wrote:
>> Does anyone have any suggestions about how to do this?  I'd like a nice
>> general technique that works for all possible subqueries, as my current
>> composition with INTERSECT does.

> One adjustment you might make is using INTERSECT ALL if you know there
> can't be duplicates. Then time won't be wasted trying to remove duplicates.

Actually, I don't think that will help.  UNION ALL is much faster than
UNION, because it doesn't have to match up duplicates, but INTERSECT
and EXCEPT still have to match rows from the inputs in order to find
out if they should emit a row at all.  IIRC there will not be any
noticeable speed difference with or without ALL.

AFAICS, what Phil will want to do is

    SELECT a FROM table1 WHERE cond11 AND cond12 AND ...
    INTERSECT
    SELECT a FROM table2 WHERE cond21 AND cond22 AND ...
    INTERSECT
    ...

which is more painful to assemble than his current approach, but it
shouldn't be *that* bad --- you just need to tag each condition with the
table it applies to, and bring together matching tags when you build the
SQL string.

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Optimisation of INTERSECT expressions
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: [ADMIN] Benchmarking postgres on Solaris/Linux