Re: Poor performance using CTE

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Poor performance using CTE
Дата
Msg-id 20121121153209.GA1271@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Poor performance using CTE  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Poor performance using CTE
Re: Poor performance using CTE
Список pgsql-performance
On 2012-11-21 10:21:16 -0500, Andrew Dunstan wrote:
>
> On 11/21/2012 09:59 AM, Tom Lane wrote:
> >Andrew Dunstan <andrew@dunslane.net> writes:
> >>If we're going to do it can we please come up with something more
> >>intuitive and much, much more documented than "OFFSET 0"? And if/when we
> >>do this we'll need to have big red warnings all over then release notes,
> >>since a lot of people I know will need to do some extensive remediation
> >>before moving to such a release.
> >The probability that we would actually *remove* that behavior of OFFSET
> >0 is not distinguishable from zero.  I'm not terribly excited about
> >having an alternate syntax to specify an optimization fence, but even
> >if we do create such a thing, there's no need to break the historical
> >usage.
> >
>
> I wasn't talking about removing it. My point was that if the optimization
> fence around CTEs is removed a lot of people will need to rework apps where
> they have used them for that purpose. And I continue to think that spelling
> it "OFFSET 0" is horribly obscure.

+1

WITH foo AS (SELECT ...) (barrier=on|off)?

9.3 introduces the syntax, defaulting to on
9.4 switches the default to off.

Greetings,

Andres Freund


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Poor performance using CTE
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Poor performance using CTE