Re: Poor performance using CTE

Поиск
Список
Период
Сортировка
От Gavin Flower
Тема Re: Poor performance using CTE
Дата
Msg-id 50ACF658.10902@archidevsys.co.nz
обсуждение исходный текст
Ответ на Re: Poor performance using CTE  (Andres Freund <andres@anarazel.de>)
Список pgsql-performance
On 22/11/12 04:32, Andres Freund wrote:
> 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
>
>

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


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




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

Предыдущее
От: Vitalii Tymchyshyn
Дата:
Сообщение: Re: SOLVED - RE: Poor performance using CTE
Следующее
От: Gavin Flower
Дата:
Сообщение: Re: Poor performance using CTE