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
-
Don't use a tuplestore if we don't have to for SQL-language functions.
- e83a8ae44729 18.0 landed
-
Change SQL-language functions to use the plan cache.
- 0dca5d68d7be 18.0 cited
-
contrib/pageinspect: Use SQL-standard function bodies.
- 68ff25eef125 18.0 cited