Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U7k8y-0001Bn-8F for pgsql-performance@arkaria.postgresql.org; Tue, 19 Feb 2013 10:09:48 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1U7k8x-000586-Og for pgsql-performance@arkaria.postgresql.org; Tue, 19 Feb 2013 10:09:47 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U7k8w-000574-Bs for pgsql-performance@postgresql.org; Tue, 19 Feb 2013 10:09:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1U7k8u-0006ow-Pi for pgsql-performance@postgresql.org; Tue, 19 Feb 2013 10:09:45 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r1JA9g9c023126; Tue, 19 Feb 2013 05:09:42 -0500 (EST) From: Tom Lane To: John Lumby cc: pgsql-performance@postgresql.org Subject: Re: slow query plans caused by under-estimation of CTE cardinality In-reply-to: References: Comments: In-reply-to John Lumby message dated "Mon, 18 Feb 2013 11:45:01 -0500" Date: Tue, 19 Feb 2013 05:09:42 -0500 Message-ID: <23125.1361268582@sss.pgh.pa.us> X-Pg-Spam-Score: -2.5 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org John Lumby writes: > Meanwhile,   I have one other suggestion aimed specifically at problematic CTEs: > Would it be reasonable to provide a new Planner Configuration option  : >   enable_nestloop_cte_inner (boolean) >   Enables or disables the query planner's use of nested-loop join plans in which a CTE is the inner. Sounds pretty badly thought out to me. There might be some cases where this would help, but there would be many more where it would be useless or counterproductive. The case that was discussed in the previous thread looked like it could be addressed by teaching the planner to drill down into CTEs to find variable referents, as it already does for subquery RTEs (cf examine_simple_variable in selfuncs.c). I'm not sure if your case is similar or not --- you didn't provide any useful amount of detail. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance