Date: Wed, 16 Apr 2025 13:27:17 -0400
From: Bruce Momjian <bruce@momjian.us>
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>,
	Pavel Stehule <pavel.stehule@gmail.com>
Subject: Re: Performance issues with v18 SQL-language-function changes
Message-ID: <Z__odasq4j8kbWlG@momjian.us>
References: <1112592.1744572204@sss.pgh.pa.us>
 <CA+Tgmobv4=R_kfdLw1ePFBr0XrCQtcK6jGFQsM=CoVeYT8Xr0Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+Tgmobv4=R_kfdLw1ePFBr0XrCQtcK6jGFQsM=CoVeYT8Xr0Q@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/Z__odasq4j8kbWlG%40momjian.us>
Precedence: bulk

On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote:
> 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.

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.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.