Re: slow query plans caused by under-estimation of CTE cardinality

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Lumby <johnlumby(at)hotmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: slow query plans caused by under-estimation of CTE cardinality
Date: 2013-02-19 10:09:42
Message-ID: 23125.1361268582@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

John Lumby <johnlumby(at)hotmail(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bastiaan Olij 2013-02-19 10:18:55 Re: Speed of exist
Previous Message Pavel Stehule 2013-02-19 07:39:31 Re: Speed of exist