Re: slow query plans caused by under-estimation of CTE cardinality
В списке pgsql-performance по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: slow query plans caused by under-estimation of CTE cardinality |
| Дата | |
| Msg-id | 23125.1361268582@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | slow query plans caused by under-estimation of CTE cardinality (John Lumby <johnlumby@hotmail.com>) |
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера