RE: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior

From: "Regina Obe" <lr(at)pcorp(dot)us>
To: "'Robert Haas'" <robertmhaas(at)gmail(dot)com>
Cc: "'PostgreSQL Hackers'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior
Date: 2019-02-22 21:27:28
Message-ID: 000801d4caf5$6a129cf0$3e37d6d0$@pcorp.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I think there are probably other ways of fixing this query that won't have
> such dramatic effects; it doesn't really seem to need to use WITH, and I bet
> you could also tweak the WITH query to prevent inlining.

Yes I know I can change THIS QUERY. I've changed other ones to work around this.
Normally I just use a LATERAL for this.

My point is lots of people use CTEs intentionally for this kind of thing because they know they are materialized.

It's going to make a lot of people hesitant to upgrade if they think they need to revisit every CTE (that they intentionally wrote cause they thought it would be materialized) to throw in a MATERIALIZED keyword.

> I also think
> Andres's question about why this gets inlined in the first place is a good one;
> the (m).* seems like it ought to be counted as a multiple reference.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL
> Company
Well if we can at least prevent the multiple reference thing from inlining that might be good enough to solve most performance regression issues that arise.

Thanks,
Regina

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-02-22 21:30:54 Re: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior
Previous Message Tom Lane 2019-02-22 21:19:10 Re: oddity with ALTER ROLE/USER