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