| 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 |
| 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 |