Re: Overhead of union versus union all

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Overhead of union versus union all
Дата
Msg-id 1247247447.26589.328.camel@monkey-cat.sm.truviso.com
обсуждение исходный текст
Ответ на Re: Overhead of union versus union all  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Overhead of union versus union all
Список pgsql-general
On Fri, 2009-07-10 at 14:22 +0100, Simon Riggs wrote:
> I mean it seems possible to prove that the distinct removal step is not
> necessary, by proving that the various sub-queries are already disjoint.
> It's a common manual optimization, so automating it seems a reasonable
> future goal.

There are even simpler cases that postgresql can't optimize. Consider:

-- foo has a primary key
SELECT * FROM foo UNION SELECT * FROM foo;

That's logically equivalent to:

SELECT * FROM foo;

But postgresql will add a sort anyway.

There are lots of optimizations along these lines. They seem obscure,
but these optimizations become much more useful when using views or
complex queries where the same table appears multiple times. For
instance, if you have two views that are projections of the same table,
then, you join the views together, you can optimize away the join in
some cases, and just scan the original table.

I think a lot of these optimizations depend on knowing which tables (or
subqueries) are relations in the relational theory sense; i.e.
unordered, distinct, and have no NULLs in the relevant attributes.

Regards,
    Jeff Davis


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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: SELECT DISTINCT very slow
Следующее
От: decibel
Дата:
Сообщение: Re: REINDEX "is not a btree"