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

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org, Alexander Pyhalov <a.pyhalov@postgrespro.ru>
Date: 2025-04-14T15:39:56Z
Lists: pgsql-hackers
Hi

po 14. 4. 2025 v 16:38 odesílatel Robert Haas <robertmhaas@gmail.com>
napsal:

> On Sun, Apr 13, 2025 at 3:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > create function fx(p_summa bigint) returns text immutable strict
> > return ltrim(to_char(p_summa, '999 999 999 999 999 999 999 999'));
> >
> > explain analyze select fx(i) from generate_series(1,1000000) as i(i);
> >
> > you arrive at the rude discovery that 0dca5d68d is about 50% slower
> > than 0dca5d68d^, because the old implementation builds a plan for fx()
> > only once and then re-uses it throughout the query.
>
> I agree that we should do something about this. I haven't reviewed
> your patches but the approach sounds broadly reasonable.
>

I can confirm that all tests passed, and patched code is about 5% faster
than the current master (tested on my slower notebook). So it should to fix
performance regression where it was it against pg17 (it was about 2%)
(tested without assertions)

Regards

Pavel




> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>

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.