Re: Performance issues with v18 SQL-language-function changes - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Performance issues with v18 SQL-language-function changes
Date
Msg-id CAFj8pRD+FO-dZ6088B81Db-ucqMvdFdjkTZQCHsZyst2y8e_kw@mail.gmail.com
Whole thread Raw
In response to Re: Performance issues with v18 SQL-language-function changes  (Robert Haas <robertmhaas@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Daria Shanina
Date:
Subject: Re: rounding_up
Next
From: Dimitrios Apostolou
Date:
Subject: [WIP] Implement "pg_restore --data-only --clean" as a way to skip WAL