Received: from makus.postgresql.org ([98.129.198.125])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <andrew@dunslane.net>) id 1TbDGw-0001m9-W0
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 16:35:35 +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 1TbDGv-00037u-69
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 16:35:34 +0000
X-Originating-IP: 217.70.178.143
Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id 7A9B91720A6;
	Wed, 21 Nov 2012 17:35:22 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter15-d.gandi.net (mfilter15-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024)
	with ESMTP id 5IWm9g13FAVx; Wed, 21 Nov 2012 17:35:20 +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 5D63A1720C7;
	Wed, 21 Nov 2012 17:35:19 +0100 (CET)
Message-ID: <50AD02C6.8070808@dunslane.net>
Date: Wed, 21 Nov 2012 11:35:18 -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: Claudio Freire <klaussfreire@gmail.com>
CC: Andres Freund <andres@2ndquadrant.com>, 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
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>
	<20121121162416.GA6268@awork2.anarazel.de>
	<CAGTBQpZc78Cmg8nuJ0HvaTRX0Bj5bTNoJUDWMpn8yd8Z9PTtAg@mail.gmail.com>
In-Reply-To: 
 <CAGTBQpZc78Cmg8nuJ0HvaTRX0Bj5bTNoJUDWMpn8yd8Z9PTtAg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201211/237
X-Sequence-Number: 48603


On 11/21/2012 11:32 AM, Claudio Freire wrote:
> On Wed, Nov 21, 2012 at 1:24 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> 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.
> set collapse_cte_limit=8;
> with blah as (blah) select blah;
>
> Not global at all.
>

Then you have to unset it again, which is ugly. You might even want it 
applying to *part* of a query, not the whole thing, so this strikes me 
as a dead end.

cheers

andrew