From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndQuadrant.com>
cc: David Greco <David_Greco@harte-hanks.com>,
	Andrew Dunstan <andrew@dunslane.net>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: SOLVED - RE: Poor performance using CTE
In-reply-to: <50A442A8.10803@2ndQuadrant.com>
References: 
 <187F6C10D2931A4386EE8E58E13857F61291D897@BY2PRD0811MB415.namprd08.prod.outlook.com>
	<20462.1352910543@sss.pgh.pa.us> <50A442A8.10803@2ndQuadrant.com>
Comments: In-reply-to Craig Ringer <craig@2ndQuadrant.com>
	message dated "Thu, 15 Nov 2012 09:17:28 +0800"
Date: Wed, 14 Nov 2012 20:31:14 -0500
Message-ID: <1159.1352943074@sss.pgh.pa.us>

Craig Ringer <craig@2ndQuadrant.com> writes:
> I was looking through the latest spec drafts I have access to and
> couldn't find any reference to Pg's optimisation-fence-for-CTEs
> behaviour being required by the standard, though I've repeatedly seen it
> said that there is such a requirement.

I don't believe it's required by the standard (it's hard to see how it
could be, when query optimization is a topic outside the spec to start
with).  However, we allow INSERT/UPDATE/DELETE RETURNING inside WITH,
and for those I think you really need to treat WITH as an optimization
fence.  It's a lot more debatable for SELECT; there are some advantages
to providing a fence this way but there are definitely downsides too.
I could see adjusting that definition in the future, as we get more
experience with use of CTEs.

			regards, tom lane