Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TbBac-0007a8-14 for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 14:47:46 +0000 Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TbBaN-0001Pe-50 for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 14:47:45 +0000 X-Originating-IP: 217.70.178.142 Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id A911F172096; Wed, 21 Nov 2012 15:47:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id EsuUyHkGT9Db; Wed, 21 Nov 2012 15:47:15 +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 3166917209C; Wed, 21 Nov 2012 15:47:14 +0100 (CET) Message-ID: <50ACE970.7050701@dunslane.net> Date: Wed, 21 Nov 2012 09:47:12 -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: Heikki Linnakangas CC: Tom Lane , Craig Ringer , Claudio Freire , Merlin Moncure , David Greco , "pgsql-performance@postgresql.org" Subject: Re: Poor performance using CTE References: <187F6C10D2931A4386EE8E58E13857F612917154@BLUPRD0811MB413.namprd08.prod.outlook.com> <50AC1472.3050607@2ndQuadrant.com> <18123.1353455585@sss.pgh.pa.us> <50ACD166.1000507@vmware.com> In-Reply-To: <50ACD166.1000507@vmware.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/225 X-Sequence-Number: 48591 On 11/21/2012 08:04 AM, Heikki Linnakangas wrote: > On 21.11.2012 01:53, Tom Lane wrote: >> I think the more interesting question is what cases wouldn't be covered >> by such a rule. Typically you need to use OFFSET 0 in situations where >> the planner has guessed wrong about costs or rowcounts, and I think >> people are likely using WITH for that as well. Should we be telling >> people that they ought to insert OFFSET 0 in WITH queries if they want >> to be sure there's an optimization fence? > > Yes, I strongly feel that we should. Writing a query using WITH often > makes it more readable. It would be a shame if people have to refrain > from using it, because the planner treats it as an optimization fence. > > If we're going to do it can we please come up with something more intuitive and much, much more documented than "OFFSET 0"? And if/when we do this we'll need to have big red warnings all over then release notes, since a lot of people I know will need to do some extensive remediation before moving to such a release. cheers andrew