Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andres@anarazel.de>) id 1TbCHl-0001AJ-Iy
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 15:32:21 +0000
Received: from mail.anarazel.de ([217.115.131.40])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andres@anarazel.de>) id 1TbCHk-0002Bs-0v
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 15:32:21 +0000
Received: by mail.anarazel.de (Postfix, from userid 108)
	id 50B6E448009; Wed, 21 Nov 2012 16:32:18 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail
X-Spam-Level: 
X-Spam-Status: No, score=-4.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00
	autolearn=ham version=3.2.5
Received: from anarazel.de (p5DDC5C2F.dip.t-dialin.net [93.220.92.47])
	(Authenticated sender: andres@anarazel.de)
	by mail.anarazel.de (Postfix) with ESMTPSA id CAE62448008;
	Wed, 21 Nov 2012 16:32:10 +0100 (CET)
Received: by anarazel.de (Postfix, from userid 1000)
	id 110831C0173; Wed, 21 Nov 2012 16:32:09 +0100 (CET)
Date: Wed, 21 Nov 2012 16:32:09 +0100
From: Andres Freund <andres@anarazel.de>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 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
Message-ID: <20121121153209.GA1271@awork2.anarazel.de>
References: 
 <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> <50ACF16C.2020902@dunslane.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50ACF16C.2020902@dunslane.net>
X-Pg-Spam-Score: -2.9 (--)
X-Archive-Number: 201211/228
X-Sequence-Number: 48594

On 2012-11-21 10:21:16 -0500, Andrew Dunstan wrote:
> 
> 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.

+1

WITH foo AS (SELECT ...) (barrier=on|off)?

9.3 introduces the syntax, defaulting to on
9.4 switches the default to off.

Greetings,

Andres Freund