Re: Poor performance using CTE - Mailing list pgsql-performance
From | Gavin Flower |
---|---|
Subject | Re: Poor performance using CTE |
Date | |
Msg-id | 50AD741E.1060100@archidevsys.co.nz Whole thread Raw |
In response to | Re: Poor performance using CTE (Craig Ringer <craig@2ndQuadrant.com>) |
List | pgsql-performance |
On 22/11/12 13:08, Craig Ringer wrote:
Are we fencing or fooing??? :-)On 11/22/2012 03:30 AM, Gavin Flower wrote:That doesn't bind tightly enough to a specific CTE term. Consider: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?
WITH
FENCE foo AS (SELECT ...),
bar AS (SELECT ...)
SELECT * FROM bar;
Are we fencing just foo? Or all expressions?-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Hmm...
How about:
(a) If we have lots of WITH SELECTS which mostly have one specific type of fencing, then we could specify the common fence value after the WITH and the exceptions after the AS:
WITH FENCE
foo AS (SELECT ...),
bar AS NOT FENCE (SELECT ...).
baz AS (SELECT ...)
SELECT * FROM bar;
alternatively:
WITH NOT FENCE
foo AS FENCE (SELECT ...),
bar AS (SELECT ...).
baz AS FENCE (SELECT ...)
SELECT * FROM bar;
(b) If we retain that FENCE is the default, then it would be simpler just to just allow a FENCE clause after the AS keyword.
WITH
foo AS (SELECT ...),
bar AS NOT FENCE (SELECT ...).
baz AS (SELECT ...)
SELECT * FROM bar;
Obviously even for (a), we have to have one value of the FENCE clause as the default. Either make the default FENCE, as now - or NOT FENCE if that is seen to be a better default, especially if that is easier for people coming from Oracle.
I suspect most people are blissfully unaware of CTE's being fenced, or at least not really sure what it means. So I suspect NOT FENCE would be the better default.
Alternative spellings might be better such as:
FENCED / NOT FENCED
or
FENCED / UNFENCED
Cheers,
Gavin
pgsql-performance by date: