Re: SOLVED - RE: Poor performance using CTE

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: SOLVED - RE: Poor performance using CTE
Дата
Msg-id CAGTBQpY=7vJOCbypUs8kD0ii5rSAYOR5WpA8z1bMduYKphL+xA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SOLVED - RE: Poor performance using CTE  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: SOLVED - RE: Poor performance using CTE  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-performance
On Tue, Nov 20, 2012 at 4:22 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Wed, Nov 14, 2012 at 8:03 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> On 15 November 2012 01:46, Andrew Dunstan <andrew@dunslane.net> wrote:
>>> It cuts both ways. I have used CTEs a LOT precisely because this behaviour
>>> lets me get better plans. Without that I'll be back to using the "offset 0"
>>> hack.
>>
>> Is the "OFFSET 0" hack really so bad? We've been telling people to do
>> that for years, so it's already something that we've effectively
>> committed to.
>
> IMSNHO, 'OFFSET 0' is completely unreadable black magic.  I agree with
> Andrew: CTEs allow for manual composition of queries and can be the
> best tool when the planner is outsmarting itself.  In the old days,
> we'd extract data to a temp table and join against that: CTE are
> essentially a formalization of that technique.  I like things the way
> they are; if CTE are hurting your plan, that's an indication you're
> using them inappropriately.

I agree, **BUT**, I cannot imagine how pushing constraints to the CTE
(under adequate conditions) could be anything but beneficial.

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).


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

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