Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TYoXd-0000Y8-QT for pgsql-performance@postgresql.org; Thu, 15 Nov 2012 01:46:53 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TYoXb-0000Pe-I7 for pgsql-performance@postgresql.org; Thu, 15 Nov 2012 01:46:53 +0000 X-Originating-IP: 217.70.178.150 Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 749D9172097; Thu, 15 Nov 2012 02:46:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eHVMnytktuXM; Thu, 15 Nov 2012 02:46:39 +0100 (CET) X-Originating-IP: 98.27.54.176 Received: from [192.168.10.146] (cpe-098-027-054-176.nc.res.rr.com [98.27.54.176]) (Authenticated sender: adsend@dunslane.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 68D79172076; Thu, 15 Nov 2012 02:46:38 +0100 (CET) Message-ID: <50A4497D.80902@dunslane.net> Date: Wed, 14 Nov 2012 20:46:37 -0500 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Craig Ringer CC: Tom Lane , David Greco , "pgsql-performance@postgresql.org" Subject: Re: SOLVED - RE: Poor performance using CTE References: <187F6C10D2931A4386EE8E58E13857F61291D897@BY2PRD0811MB415.namprd08.prod.outlook.com> <20462.1352910543@sss.pgh.pa.us> <50A442A8.10803@2ndQuadrant.com> In-Reply-To: <50A442A8.10803@2ndQuadrant.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/176 X-Sequence-Number: 48542 On 11/14/2012 08:17 PM, Craig Ringer wrote: > On 11/15/2012 12:29 AM, Tom Lane wrote: >> David Greco writes: >>> Thanks, that did the trick. Though I'm still not clear as to why. >> PG treats WITH as an optimization fence --- the WITH query will be >> executed pretty much as-is. It may be that Oracle flattens the query >> somehow; though if you're using black-box functions in both cases, >> it's not obvious where the optimizer could get any purchase that way. >> > 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. > > Do you know where it's specified? > > All I can see is that the optimised result must have the same effect as > the original. That'd mean that wCTEs and CTE terms that use VOLATILE > functions or functions with side-effects couldn't be optimised into > other queries. Simple CTEs could be, though, and there are times I've > really wished I could use a CTE but I've had to use a set-returning > subquery to get reasonable plans. It cuts both ways. I have used CTEs a LOT precisely because this behaviour lets me get better plans. Without that I'll be back to using the "offset 0" hack. cheers andrew