Re: Poor performance using CTE
От | Gavin Flower |
---|---|
Тема | Re: Poor performance using CTE |
Дата | |
Msg-id | 50AD2BD1.8070206@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Poor performance using CTE (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-performance |
On 22/11/12 04:56, Heikki Linnakangas wrote:
On 21.11.2012 17:42, Gavin Flower wrote:WITH FENCE foo AS (SELECT ...)On 22/11/12 04:32, Andres Freund wrote:On 2012-11-21 10:21:16 -0500, Andrew Dunstan wrote:I wasn't talking about removing it. My point was that if the+1
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.
FWIW, I'm happy with "OFFSET 0". Granted, it's pretty obscure, but that's what we've historically recommended, and it's pretty ugly to have to specify a fence like that in the first place. Whenever you have to resort to it, you ought have a comment in the query explaining why you need to force the planner like that, anyway.WITH foo AS (SELECT ...) (barrier=on|off)?
9.3 introduces the syntax, defaulting to on
9.4 switches the default to off.
WITH foo AS (SELECT ...) (fence=on|off)?
WITH foo AS (SELECT ...) (optimisation_fence=on|off)?
If we are to invent a new syntax for this, can we please come up with something that's more widely applicable than just the WITH syntax. Something that you could use to replace OFFSET 0 in a subquery, too.
- Heikki
default?
WITHOUT FENCE foo AS (SELECT ...) :-)
Nah!
I prefer this, but it is too specific to 'WITH',
and very unSQL standardish!
Alternatively one of the following
- WITH UNFENCED foo AS (SELECT ...)
- WITH NO FENCE foo AS (SELECT ...)
- WITH NOT FENCE foo AS (SELECT ...)
most SQL standardish!
Cheers,
Gavin
В списке pgsql-performance по дате отправления: