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-Wzk69bmHD9YnpyHOkv=o=dzQ=SeYtMbcpaTXnRo-wnQ7NA@mail.gmail.com
Whole thread Raw
In response to Re: strange perf regression with data checksums  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
On Mon, May 19, 2025 at 3:37 PM Andres Freund <andres@anarazel.de> wrote:
> I think we can do better - something like
>
> #ifdef PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY
>     lsn = PageGetLSN(page);
> #else
>     buf_state = LockBufHdr(bufHdr);
>     lsn = PageGetLSN(page);
>     UnlockBufHdr(bufHdr, buf_state);
> #endif
>
> All perf relevant systems support reading 8 bytes without a chance of
> tearing...

Even assuming that this scheme works perfectly, I'd still like to
pursue the idea I had about fixing this in nbtree.

The relevant nbtree code seems more elegant if we avoid calling
BufferGetLSNAtomic() unless and until its return value might actually
be useful. It's quite a lot easier to understand the true purpose of
so->currPos.lsn with this new structure.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Should we optimize the `ORDER BY random() LIMIT x` case?
Next
From: Peter Geoghegan
Date:
Subject: Re: strange perf regression with data checksums