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 CAFj8pRDNm-BcJuqYe=A0FAVj3VaBAKSGBgKmX7Gjhjy94ZZ7Ng@mail.gmail.com
Whole thread Raw
In response to Re: Performance issues with v18 SQL-language-function changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi

st 16. 4. 2025 v 19:43 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
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.

yes, and for most cases it has significant performance benefits.  For a few corner cases, there can be some slowdown that can be fixed by last Tom patches.

Regards

Pavel


                        regards, tom lane

pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: pgsql: Non text modes for pg_dumpall, correspondingly change pg_restore
Next
From: Alexander Lakhin
Date:
Subject: Re: recoveryCheck test failure on flaviventris