| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Remove no-op PlaceHolderVars |
| Date: | 2026-01-16 03:37:28 |
| Message-ID: | 1004090.1768534648@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> While fixing some performance issues caused by PHVs recently, it
> struck me again that we should be removing "no-op" PHVs whenever
> possible, because PHVs can be optimization barriers in several cases.
My immediate reaction is "how sure are you that they're no-ops"?
I recall that there are places where we intentionally insert PHVs
to preserve the separate identity of the contained expression
(so that, for example, it can be matched to a subquery output
later).
> I still do not have a good idea for ensuring that removing the PHV
> wrapper does not break the expression tree invariants. But maybe we
> can use a conservative approach: we only strip the PHV if the
> contained expression is known to be safe (for example, a simple Var).
Do we generate a PHV at all in that case? Seems like we could
deal with that by adding to the Var's varnullingrels instead of
making a wrapper node.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-01-16 03:41:37 | Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication |
| Previous Message | Richard Guo | 2026-01-16 03:27:36 | Re: Fwd: pg18 bug? SELECT query doesn't work |