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 по дате отправления: