Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb9yx-0006kP-PD for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 13:04:47 +0000 Received: from smtp-outbound-2.vmware.com ([208.91.2.13]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tb9yv-0008CD-Fd for pgsql-performance@postgresql.org; Wed, 21 Nov 2012 13:04:45 +0000 Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 39D712832A; Wed, 21 Nov 2012 05:04:44 -0800 (PST) Received: from zcs-prod-ext-mta-1.vmware.com (zcs-prod-ext-mta-1.vmware.com [10.113.62.223]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 3545A1867E; Wed, 21 Nov 2012 05:04:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTP id 9EB2F121995; Wed, 21 Nov 2012 05:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at zcs-prod-ext-mta-1.vmware.com Received: from zcs-prod-ext-mta-1.vmware.com ([127.0.0.1]) by localhost (zcs-prod-ext-mta-1.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SGTjNAANqR-1; Wed, 21 Nov 2012 05:05:22 -0800 (PST) Received: from [192.168.1.90] (unknown [10.113.62.14]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTPSA id 0934F121991; Wed, 21 Nov 2012 05:05:20 -0800 (PST) Message-ID: <50ACD166.1000507@vmware.com> Date: Wed, 21 Nov 2012 15:04:38 +0200 From: Heikki Linnakangas Organization: VMware User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: Tom Lane CC: 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> In-Reply-To: <18123.1353455585@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -7.2 (-------) X-Archive-Number: 201211/221 X-Sequence-Number: 48587 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. - Heikki