| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fwd: [patch] bufmgr Half state CAS |
| Date: | 2026-10-14 21:07:29 |
| Message-ID: | fnrfw2no7hwa5pg24zfmljgz26ahmlufkq2ue365f7iy4amahw@n42iohfhyuwi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-10-14 21:53:21 +0100, Alexandre Felipe wrote:
> See attached, running on top of 10cc5aa96a6 I got
>
> clients base patched
>
> 1 3251.2 3221.3
> 8 2592.2 3979.0 *+53.5%*
Given how low the throughput is, you must be testing read/write pgbench. Is
that right? If so, it's completely inconceivable that that lwock efficiency
has that kind of impact at such low throughput & concurrency. You're waiting
for the disk, not a CAS retry. It'd be more likely that what you're measuring
WAL file initialization overhead or such.
There's no way that you'd ever see any meaningful benefits of something like
this until you reach much much higher concurrency. The timeframe between
reading the "old" value and the CAS is very short, it's pretty hard to steal
the cacheline in that window and modify it.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2026-10-14 21:18:50 | Re: [PG19] pg_dump --statistics restores extended statistics by attribute number |
| Previous Message | Mircea Cadariu | 2026-10-14 20:59:10 | Re: parallel data loading for pgbench -i |