Horton

Re: SQLFunctionCache and generic plans

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

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Alexander Pyhalov <a.pyhalov@postgrespro.ru>, Alexander Korotkov <aekorotkov@gmail.com>, pgsql-hackers@lists.postgresql.org, Ronan Dunklau <ronan.dunklau@aiven.io>
Date: 2025-02-27T20:45:33Z
Lists: pgsql-hackers 
Pavel Stehule <pavel.stehule@gmail.com> writes:
> čt 27. 2. 2025 v 20:52 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>> So taken together, our results are all over the map, anywhere
>> from 7% speedup to 7% slowdown.  My usual rule of thumb is that

> Where do you see 7% speedup? Few lines up you wrote 0.7% faster.

Alexander got that on the fx4 case, according to his response a
few messages ago [1].  It'd be good if someone else could reproduce
that, because right now we have two "it's slower" results versus
only one "it's faster".

			regards, tom lane

[1] https://www.postgresql.org/message-id/e5724d1ba8398c7ff20ead1de73b4db4%40postgrespro.ru

Commits

  1. Fix performance issue in deadlock-parallel isolation test.

  2. functions.c: copy trees from source_list before parse analysis etc.

  3. Fix oversight in commit 0dca5d68d.

  4. Change SQL-language functions to use the plan cache.

  5. Reordering DISTINCT keys to match input path's pathkeys