From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Remove no-op PlaceHolderVars
In-reply-to: <CAMbWs4-_fDPOiYJWj330pJS++kKbTw_EfO5-pC8nPKHUAScMWw@mail.gmail.com>
References: <CAMbWs48biJp-vof82PNP_LzzFkURh0W+RKt4phoML-MyYavgdg@mail.gmail.com> <1346382.1725334280@sss.pgh.pa.us> <CAMbWs48vC37+j0V1SnHGRTP55AAaFyAYEbYGzh7UBKoWfh=E0w@mail.gmail.com> <CAMbWs4-_fDPOiYJWj330pJS++kKbTw_EfO5-pC8nPKHUAScMWw@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Fri, 16 Jan 2026 11:49:38 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1004089.1768534648.1@sss.pgh.pa.us>
Date: Thu, 15 Jan 2026 22:37:28 -0500
Message-ID: <1004090.1768534648@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1004090.1768534648%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.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