Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andres@2ndquadrant.com>) id 1TbD6B-00042d-1W
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 16:24:27 +0000
Received: from moutng.kundenserver.de ([212.227.17.8])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andres@2ndquadrant.com>) id 1TbD68-00073B-18
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 16:24:26 +0000
Received: from anarazel.de (p5DDC5C2F.dip.t-dialin.net [93.220.92.47])
	by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
	id 0MZwWl-1Tpry901cN-00Lv7A; Wed, 21 Nov 2012 17:24:18 +0100
Received: by anarazel.de (Postfix, from userid 1000)
	id E58171C0173; Wed, 21 Nov 2012 17:24:16 +0100 (CET)
Date: Wed, 21 Nov 2012 17:24:16 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Tom Lane <tgl@sss.pgh.pa.us>,
	Heikki Linnakangas <hlinnakangas@vmware.com>,
	Craig Ringer <craig@2ndquadrant.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: <20121121162416.GA6268@awork2.anarazel.de>
References: 
 <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>
	<20121121153209.GA1271@awork2.anarazel.de>
	<CAGTBQpa14GQ+L9KSKdS+kXVWYkoEVNUBbvaUpgRjskufEx-=-A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAGTBQpa14GQ+L9KSKdS+kXVWYkoEVNUBbvaUpgRjskufEx-=-A@mail.gmail.com>
X-Provags-ID: V02:K0:x1/ZJSlNZfvgddnz5IbAjuZvLd3731mZCmRJ48hyBel
	VBdGuEcpqpoYnWgwVB6FvYgkx7mPPavFvYzk8trlr6NoQ9RpR5
	wzLQbK6TjZIuYEhe2ZMFYwJgs815uZryFFyI+O6YD2o8t1geW4
	kc1ZXdUgHzkYgGPgLak3yu7FEFJVgN/YuzvhC7HlEvbAMj4yT/
	mvPGOziXULoHg1ZGMQV5jIMei+KzNuVyXQsaFud2dVRdz1as4p
	JVjDjtKjrr17Rwbj1EYv3idZaUQXqYG/nUUJNdc32JqYSkacKa
	LVM5Bz2D0GFRTPOsHoJGXqR4ZZtdYJgBjCzE1cMqQter+araZB
	rIJJ+BsFTFYd1POz7b0mE6VDSGCmK08uxN4IpvlDa
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201211/233
X-Sequence-Number: 48599

On 2012-11-21 13:16:25 -0300, Claudio Freire wrote:
> On Wed, Nov 21, 2012 at 12:32 PM, Andres Freund <andres@anarazel.de> wrote:
> > +1
> >
> > WITH foo AS (SELECT ...) (barrier=on|off)?
> >
> > 9.3 introduces the syntax, defaulting to on
> > 9.4 switches the default to off.
>
> Why syntax? What about a guc?
>
> collapse_cte_limit?

Because there are very good reasons to want to current behaviour. A guc
is a global either/or so I don't see it helping much.

Greetings,

Andres Freund

--
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services