Re: future of PQfn()

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: future of PQfn()
Date: 2026-05-27 18:23:04
Message-ID: ahc2iM2KRMyOWBPS@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 26, 2026 at 11:36:49PM +0200, Jelte Fennema-Nio wrote:
> 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.

The test is just:

int main()
{
PCconn *conn = PQsetdb(NULL, NULL, NULL, NULL, "postgres");

for (int i = 0; i < 1000000; i++)
lo_create(conn, i);

for (int i = 0; i < 1000000; i++)
lo_unlink(conn, i);
}

Before applying your patch -> 0.457 seconds (best of ~10)
After applying your patch -> 0.444 seconds (best of ~10)

For reference, HEAD runs this test in 0.319 seconds.

I've attached my work-in-progress patches here, in case you're interested.
0001 switches the frontend LO interface to use prepared statements, and
0002 removes PQfn() entirely. 0003 applies on top of those two and
switches the frontend LO interface to use PQexecParams() instead.

--
nathan

Attachment Content-Type Size
v1-0001-stop-using-PQfn-in-libpq-s-LO-interface.patch text/plain 25.7 KB
v1-0002-remove-support-for-PQfn.patch text/plain 17.0 KB
v1-0003-LO-frontend-PQexecParams.patch text/plain 13.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-05-27 18:25:19 Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)
Previous Message Matheus Alcantara 2026-05-27 18:22:15 Re: postgres_fdw, dblink: Validate use_scram_passthrough values