From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Smith <gregsmithpgsql(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Major pgbench synthetic SELECT workload regression, Ubuntu 23.04+PG15 |
Date: | 2023-06-08 19:52:53 |
Message-ID: | 140065.1686253973@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Smith <gregsmithpgsql(at)gmail(dot)com> writes:
> Pushing SELECT statements at socket speeds with prepared statements is a
> synthetic benchmark that normally demos big pgbench numbers. My benchmark
> farm moved to Ubuntu 23.04/kernel 6.2.0-20 last month, and that test is
> badly broken on the system PG15 at larger core counts, with as much as an
> 85% drop from expectations.
> ... I could use some confirmation of where this happens from
> other tester's hardware and Linux kernels.
FWIW, I can't reproduce any such effect with PG HEAD on RHEL 8.8
(4.18.0 kernel) or Fedora 37 (6.2.14 kernel). Admittedly this is
with less-beefy hardware than you're using, but your graphs say
this should be obvious with even a dozen clients, and I don't
see that. I'm getting results like
$ pgbench -S -T 10 -c 16 -j 16 -M prepared pgbench
tps = 472503.628370 (without initial connection time)
$ pgbench -S -T 10 -c 16 -j 16 pgbench
tps = 297844.301319 (without initial connection time)
which is about what I'd expect.
Could it be that the breakage is Ubuntu-specific? Seems unlikely,
but ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2023-06-08 19:57:51 | Re: Named Prepared statement problems and possible solutions |
Previous Message | Jan Wieck | 2023-06-08 19:49:55 | Re: Named Prepared statement problems and possible solutions |