Re: slow query plans caused by under-estimation of CTE cardinality - Mailing list pgsql-performance

From Tom Lane
Subject Re: slow query plans caused by under-estimation of CTE cardinality
Date
Msg-id 23125.1361268582@sss.pgh.pa.us
Whole thread Raw
In response to slow query plans caused by under-estimation of CTE cardinality  (John Lumby <johnlumby@hotmail.com>)
List pgsql-performance
John Lumby <johnlumby@hotmail.com> 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


pgsql-performance by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Speed of exist
Next
From: Bastiaan Olij
Date:
Subject: Re: Speed of exist