Re: SOLVED - RE: Poor performance using CTE - Mailing list pgsql-performance

From Vitalii Tymchyshyn
Subject Re: SOLVED - RE: Poor performance using CTE
Date
Msg-id CABWW-d027Zhb4bd7u34aJLD0+647RVfP10QytBN-q3dLjiwuLQ@mail.gmail.com
Whole thread Raw
In response to Re: SOLVED - RE: Poor performance using CTE  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-performance

I'd also add ANALYZED/NOT ANALYZED. This should force it behave like 'create table, analyze, select' with statistics used in second query plan.

P.S. defaults can be configurable.

20 лист. 2012 02:22, "Gavin Flower" <GavinFlower@archidevsys.co.nz> напис.
On 15/11/12 15:03, Peter Geoghegan wrote:
On 15 November 2012 01:46, Andrew Dunstan <andrew@dunslane.net> wrote:
It cuts both ways. I have used CTEs a LOT precisely because this behaviour
lets me get better plans. Without that I'll be back to using the "offset 0"
hack.
Is the "OFFSET 0" hack really so bad? We've been telling people to do
that for years, so it's already something that we've effectively
committed to.

How about adding the keywords FENCED and NOT FENCED to the SQL definition of CTE's - with FENCED being the default?


Cheers,
Gavin



--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

pgsql-performance by date:

Previous
From: Jon Nelson
Date:
Subject: Re: Poor performance using CTE
Next
From: Gavin Flower
Date:
Subject: Re: Poor performance using CTE