Re: PostgreSQL select-only CTE removal is too aggressive?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PostgreSQL select-only CTE removal is too aggressive?
Date: 2026-06-29 20:22:06
Message-ID: 2028298.1782764526@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kirill Reshke <reshkekirill(at)gmail(dot)com> writes:
> I have been thinking for a while about this optimization. The thing is,
> there is currently no way of forcing this CTE evaluation other than
> referencing it from other query parts. I think this is little clumsy. What
> if we use MATERIALIZE here for this purpose? So,
> WITH d as MATERIALIZED (select f()) select 1 ;
> will force evaluation? Does this strike you as good idea?

No. What is the point?

Also, this would be far from a one-liner change. Stopping the
planner from throwing away unreferenced CTEs wouldn't cause the
executor to run them. Currently the executor only pays attention
to running ModifyTable nodes to completion.

The short answer here is that this feature has behaved like this since
we implemented it, in 2008 (cf commit 44d5be0e5). AFAIR you are the
first to complain about it. You should seriously consider the
possibility that it's you that are mistaken about the value of doing
things differently. Even if there is some value, I think that
backwards compatibility would argue against changing the semantics.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-06-29 21:13:00 Multi-insert for logical replication apply
Previous Message Peter Smith 2026-06-29 20:21:39 Re: pg_createsubscriber --dry-run logging concerns