Horton

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

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

View thread View on postgr.es
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-16T19:13:20Z
Lists: pgsql-hackers 
Bruce Momjian <bruce@momjian.us> writes:
> On Wed, Apr 16, 2025 at 01:43:46PM -0400, Tom Lane wrote:
>> I'm confused?  0dca5d68d didn't have anything to do with
>> syntax changes, just with when planning happens.

> I was referencing the contrib initialization functions you converted to
> use SQL-standard function bodies:

Nah, that's not really relevant.  The speed concerns I have here
are mostly independent of whether the SQL function is written
in string or SQL-standard form.  Also, I think all of those
contrib functions that are at all performance-relevant are
capable of being inlined, and so wouldn't reach this code anyway.

			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.