Re: future of PQfn() - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: future of PQfn()
Date
Msg-id DISXKTNN3JUM.30KZW8W94LPVO@jeltef.nl
Whole thread
List pgsql-hackers
On Tue, 26 May 2026 at 18:05, Nathan Bossart <nathandbossart@gmail.com>
wrote:
> Another approach we
> could take is to just send the query via PQexecParams(), but a simple test
> (creating and unlinking 10K LOs) showed a ~41% slowdown compared to HEAD.
> So, I guess we'll need to keep PQnfn() around for now...
>
> Thoughts?

I had a small WIP patch (fully AI generated and not yet vetted by me)
lying around for unrelated reasons to make the extended protocol perform
closer to the simple protocol with pgbench --select-only by using
CreateOneShotCachedPlan to create the plan for unnamed prepared
statements (see attached).

Could you share the simple LO test you were running here and/or rerun it
with this patch applied? I'd love to know if the patch reduces the
slowdown significantly, or if something else is the bottleneck.

Attachment

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: First draft of PG 19 release notes
Next
From: Bruce Momjian
Date:
Subject: Re: First draft of PG 19 release notes