Re: CTE Changes in PostgreSQL 12, can we have a GUC to get oldbehavior
От | Andres Freund |
---|---|
Тема | Re: CTE Changes in PostgreSQL 12, can we have a GUC to get oldbehavior |
Дата | |
Msg-id | 20190222213209.ojylrztgbesybz7g@alap3.anarazel.de обсуждение исходный текст |
Ответ на | RE: CTE Changes in PostgreSQL 12, can we have a GUC to get old behavior ("Regina Obe" <lr@pcorp.us>) |
Список | pgsql-hackers |
Hi, On 2019-02-22 16:27:28 -0500, Regina Obe wrote: > > 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 intentionallywrote cause they thought it would be materialized) to throw in a MATERIALIZED keyword. This was extensively discussed, in several threads about inlining CTEs. But realistically, it doesn't actually solve the problem to offer a GUC, because we'd not be able to remove it anytime soon. I see benefit in discussing how we can address regressions like your example query here, but I don't feel there's any benefit in re-opening the whole discussion about GUCs, defaults, and whatnot. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: