Re: scenario with a slow query

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: scenario with a slow query
Дата
Msg-id 25162.1326910101@sss.pgh.pa.us
обсуждение исходный текст
Ответ на scenario with a slow query  (Volodymyr Kostyrko <c.kworr@gmail.com>)
Ответы Transaction ID wraparound, Oracle style  (Igor Polishchuk <igor@powerreviews.com>)
Re: scenario with a slow query  (Volodymyr Kostyrko <c.kworr@gmail.com>)
Список pgsql-general
Volodymyr Kostyrko <c.kworr@gmail.com> writes:
> Maybe I'm missing something but I have found a case when planner is
> unoptimal.

The planner knows next to nothing about optimizing FULL JOIN, and
I would not recommend holding your breath waiting for it to get better
about that, because there's basically no demand for the work that'd
be involved.  I'd suggest refactoring this query instead.  A nest of
full joins seems like a rather unintuitive way to get the result
anyway ...

            regards, tom lane

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

Предыдущее
От: "A.M."
Дата:
Сообщение: Re: Table permissions
Следующее
От: Igor Polishchuk
Дата:
Сообщение: Transaction ID wraparound, Oracle style