Postgres Pro
Downloads
Home   >   mailing lists

Thread: Query plan regression between CTE and views

Query plan regression between CTE and views

From
David Gilman
Date:
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.

-- 
David Gilman
:DG<

Re: Query plan regression between CTE and views

From
Ron
Date:
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.

Re: Query plan regression between CTE and views

From
David Gilman
Date:
I'm on PostgreSQL 15 with essentially a stock configuration.

On Tue, Aug 15, 2023 at 8:58 AM Ron <ronljohnsonjr@gmail.com> wrote:
>
> 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.
>
>
>
>


--
David Gilman
:DG<