Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1TbDoG-00034H-KF
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 17:10:00 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <tgl@sss.pgh.pa.us>) id 1TbDoE-0007lf-T9
	for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 17:10:00 +0000
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id qALH9owx006039;
	Wed, 21 Nov 2012 12:09:50 -0500 (EST)
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
cc: Andres Freund <andres@2ndquadrant.com>,
	Andrew Dunstan <andrew@dunslane.net>,
	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
In-reply-to: 
 <CAGTBQpZc78Cmg8nuJ0HvaTRX0Bj5bTNoJUDWMpn8yd8Z9PTtAg@mail.gmail.com>
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>
Comments: In-reply-to Claudio Freire <klaussfreire@gmail.com>
	message dated "Wed, 21 Nov 2012 13:32:45 -0300"
Date: Wed, 21 Nov 2012 12:09:50 -0500
Message-ID: <6038.1353517790@sss.pgh.pa.us>
X-Pg-Spam-Score: -2.2 (--)
X-Archive-Number: 201211/239
X-Sequence-Number: 48605

Claudio Freire <klaussfreire@gmail.com> writes:
> collapse_cte_limit?

The join collapse limits address a completely different problem (ie,
explosion of planning time with too many relations), and are pretty much
useless as a model for this.  As multiple people told you already,
optimization fences are typically wanted for only specific subqueries.

			regards, tom lane