Re: Query plan regression between CTE and views

Поиск
Список
Период
Сортировка
От Ron
Тема Re: Query plan regression between CTE and views
Дата
Msg-id 30357cd7-d085-88b3-ad33-47636578911c@gmail.com
обсуждение исходный текст
Ответ на Query plan regression between CTE and views  (David Gilman <davidgilman1@gmail.com>)
Ответы Re: Query plan regression between CTE and views
Список pgsql-general
On 8/14/23 09:54, David Gilman wrote:
> I have a query that was originally written as a handful of CTEs out of
> convenience. It is producing a reasonable query plan because the CTE
> materialization was kicking in at an appropriate place. The CTEs
> aren't totally linear. The graph looks like this, where A, B, C and D
> are CTEs, and B -> A means B selects from A. In Graphviz format:
>
> G {
>     B -> A;
>     C -> A;
>     C -> B;
>     D -> C;
> }
>
> Out of curiosity I tried turning the query into a series of views and
> ran that query. The query plan is vastly different, there is no
> materialization and it runs much slower.
>
> My question is: is this a valid bug? I am not sure if I should expect
> the view version to find a way to materialize and produce a comparable
> query plan. Also, making a minimal test case is going to take a bit
> and I don't want to start unless this smells like a genuine bug.


What version of Postgresql?

(Also, back before, I think, v12, CTEs were optimizer fences.  You were 
better using views or sub-queries.)

-- 
Born in Arizona, moved to Babylonia.



В списке pgsql-general по дате отправления:

Предыдущее
От: Sai Teja
Дата:
Сообщение: Re: Fatal Error : Invalid Memory alloc request size 1236252631
Следующее
От: David Ventimiglia
Дата:
Сообщение: How to optimize PostgreSQL Row Security Policies that involve related tables?