From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Greco <David_Greco(at)harte-hanks(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: SOLVED - RE: Poor performance using CTE |
Date: | 2012-11-15 18:26:17 |
Message-ID: | 50A533C9.9000701@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 15/11/12 15:03, Peter Geoghegan wrote:
> On 15 November 2012 01:46, Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Antti Jokipii | 2012-11-15 19:20:07 | Query that uses lots of memory in PostgreSQL 9.2.1 in Windows 7 |
Previous Message | Maria L. Wilson | 2012-11-15 15:59:16 | slow query on postgres 8.4 |