Re: Performance issues with v18 SQL-language-function changes

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org, Alexander Pyhalov <a.pyhalov@postgrespro.ru>, Pavel Stehule <pavel.stehule@gmail.com>
Date: 2025-04-16T17:43:46Z
Lists: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote:
>> I agree that we should do something about this. I haven't reviewed
>> your patches but the approach sounds broadly reasonable.

> Yep, we went down the road in PG 18 to convert syntax, and now we have
> to fix this, or we have to revert all the PG 18 syntax changes, which
> seems like a step backward.

I'm confused?  0dca5d68d didn't have anything to do with
syntax changes, just with when planning happens.

			regards, tom lane



Commits

  1. Don't use a tuplestore if we don't have to for SQL-language functions.

  2. Change SQL-language functions to use the plan cache.

  3. contrib/pageinspect: Use SQL-standard function bodies.