Re: Fwd: [patch] bufmgr Half state CAS

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

In response to

Browse pgsql-hackers by date

  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