Re: SOLVED - RE: Poor performance using CTE

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: SOLVED - RE: Poor performance using CTE
Дата
Msg-id CAHyXU0w4OiA0Lg35Y0jJfp80GPAYjb6TivjYexMSuO-02aGN8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SOLVED - RE: Poor performance using CTE  (Claudio Freire <klaussfreire@gmail.com>)
Ответы Re: SOLVED - RE: Poor performance using CTE
Re: SOLVED - RE: Poor performance using CTE
Список pgsql-performance
On Tue, Nov 20, 2012 at 1:53 PM, Jon Nelson <jnelson+pgsql@jamponi.net> wrote:
> As can be seen by the current conversation, not everyone is convinced
that CTEs ought to be an explicit optimization barrier

On Tue, Nov 20, 2012 at 1:26 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> It *could* just be a lack of imagination on my part. But if it were
> not, then it'd be nice for it to be done automatically (since this
> particular CTE behavior bites enough people already).

Sure.  I just find it personally hard to find a good demarcation line
between A: "queries where pushing quals through are universally
beneficial and wanted" and B: "queries where we are inserting an
explicit materialization step to avoid planner issues", particularly
where there is substantial overlap with between A and C: "queries that
are written with a CTE and arguably shouldn't be".

Put another way, I find CTE to express: 'this then that' where joins
express 'this with that'.  So current behavior is not surprising at
all. All that said, there could be a narrow class of low hanging cases
(such as the OP's) that could be sniped...I'm just skeptical.

merlin


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

Предыдущее
От: Jon Nelson
Дата:
Сообщение: Re: SOLVED - RE: Poor performance using CTE
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: SOLVED - RE: Poor performance using CTE