Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 70669B5DD43 for ; Wed, 2 Nov 2011 17:03:27 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 79912-08-2 for ; Wed, 2 Nov 2011 20:03:21 +0000 (UTC) X-Greylist: delayed 00:28:28.16305 by SQLgrey-1.8.0-rc2 Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mail.postgresql.org (Postfix) with ESMTP id 98ED1B5DDBA for ; Wed, 2 Nov 2011 17:03:06 -0300 (ADT) Received: by pzk32 with SMTP id 32so1619092pzk.3 for ; Wed, 02 Nov 2011 13:03:06 -0700 (PDT) Received: by 10.68.73.40 with SMTP id i8mr6705956pbv.45.1320262477379; Wed, 02 Nov 2011 12:34:37 -0700 (PDT) Received: from Craig-Jamess-MacBook-Pro.local (wsip-70-167-122-86.sd.sd.cox.net. [70.167.122.86]) by mx.google.com with ESMTPS id p6sm7073118pbf.3.2011.11.02.12.34.35 (version=SSLv3 cipher=OTHER); Wed, 02 Nov 2011 12:34:35 -0700 (PDT) Message-ID: <4EB19C78.8030903@emolecules.com> Date: Wed, 02 Nov 2011 12:39:36 -0700 From: Craig James User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Guide to PG's capabilities for inlining, predicate hoisting, flattening, etc? References: <29918.1320244719@sss.pgh.pa.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201111/25 X-Sequence-Number: 45536 On 11/2/11 10:22 AM, Claudio Freire wrote: > On Wed, Nov 2, 2011 at 12:13 PM, Robert Haas wrote: >> I wonder if we need to rethink, though. We've gotten a number of >> reports of problems that were caused by single-use CTEs not being >> equivalent - in terms of performance - to a non-CTE formulation of the >> same idea. It seems necessary for CTEs to behave this way when the >> subquery modifies data, and there are certainly situations where it >> could be desirable otherwise, but I'm starting to think that we >> shouldn't do it that way by default. Perhaps we could let people say >> something like WITH x AS FENCE (...) when they want the fencing >> behavior, and otherwise assume they don't (but give it to them anyway >> if there's a data-modifying operation in there). > Well, in my case, I got performance thanks to CTEs *being* > optimization fences, letting me fiddle with query execution. > > And I mean, going from half-hour queries to 1-minute queries. Same here. It was a case where I asked this group and was told that putting an "offset 0" fence in was probably the only way to solve it (once again reminding us that Postgres actually does have hints ... they're just called other things). > It is certainly desirable to maintain the possibility to use fences when needed. Indeed. Optimizer problems are usually fixed in due course, but these "fences" are invaluable when you have a dead web site that has to be fixed right now. Craig