Re: strange perf regression with data checksums - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: strange perf regression with data checksums
Date
Msg-id CAH2-Wz=3-4srTde8WETyBVPjAL+i4PJ_oWj+Q3FkakkbHaHKsw@mail.gmail.com
Whole thread Raw
In response to Re: strange perf regression with data checksums  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: strange perf regression with data checksums
List pgsql-hackers
On Mon, May 19, 2025 at 4:17 PM Tomas Vondra <tomas@vondra.me> wrote:
> Same effect as v1 for IOS, with regular index scans I see this:
>
> 64 clients: 0.7M tps
> 96 clients: 1.5M tps
>
> So very similar improvement as for IOS.

Just to be clear, you're saying my v2 appears to fix the problem
fully, for both plain index scans and index-only scans? (You haven't
mentioned bitmap index scans at all, I think, even though they are
relevant to v2.)

I'd be surprised if my v2 *fully* fixed the issue with plain index
scans. It's only going to avoid calls to BufferGetLSNAtomic()
following _bt_readpage calls that return false, but I doubt that your
particular pgbench-variant test queries really look like that.

*Looks again* Oh, wait. This is another one of those benchmarks with
an index scan that returns no rows whatsoever (just like on the other
recent thread involving regressions tied to the introduction of a new
skip support support function to nbtree). Fully makes sense that my v2
would fix that particular problem, even with plain index scans.
But...what about slightly different queries, that actually do return
some rows? Those will look different.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: strange perf regression with data checksums
Next
From: Nathan Bossart
Date:
Subject: Re: regdatabase