Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andrew@dunslane.net>) id 1TbC7J-0000ON-E5
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 15:21:33 +0000
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andrew@dunslane.net>) id 1TbC7H-0001xo-U0
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 15:21:32 +0000
X-Originating-IP: 217.70.178.146
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 88AC71720CC;
	Wed, 21 Nov 2012 16:21:20 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id oDee0aTk+vlM; Wed, 21 Nov 2012 16:21:19 +0100 (CET)
X-Originating-IP: 98.27.58.255
Received: from [192.168.10.146] (cpe-098-027-058-255.nc.res.rr.com
	[98.27.58.255]) (Authenticated sender: adsend@dunslane.net)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E16E91720B3;
	Wed, 21 Nov 2012 16:21:17 +0100 (CET)
Message-ID: <50ACF16C.2020902@dunslane.net>
Date: Wed, 21 Nov 2012 10:21:16 -0500
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Heikki Linnakangas <hlinnakangas@vmware.com>,
	Craig Ringer <craig@2ndQuadrant.com>,
	Claudio Freire <klaussfreire@gmail.com>,
	Merlin Moncure <mmoncure@gmail.com>,
	David Greco <David_Greco@harte-hanks.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Poor performance using CTE
References: 
 <187F6C10D2931A4386EE8E58E13857F612917154@BLUPRD0811MB413.namprd08.prod.outlook.com>
	<CAHyXU0xeEVX2P=HaNxPiKayEhkWp3GobgAXCQPrfsqbawXVV-w@mail.gmail.com>
	<CAGTBQpZ_Za-XSXvmPUx3F7wgeX=HB1xUpDsn+1DXY3a87YJLBQ@mail.gmail.com>
	<CAHyXU0z4oUss50vhH_wGZ-HERQe9wCMSf1nMTGNddXeCoKvVVA@mail.gmail.com>
	<CAGTBQpbf9bdJ3gjcYdw2FuPmN=dqx+wE7opsCp515cEndpGDYw@mail.gmail.com>
	<50AC1472.3050607@2ndQuadrant.com>
	<18123.1353455585@sss.pgh.pa.us> <50ACD166.1000507@vmware.com>
	<50ACE970.7050701@dunslane.net> <3396.1353509947@sss.pgh.pa.us>
In-Reply-To: <3396.1353509947@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201211/227
X-Sequence-Number: 48593


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.

cheers

andrew