From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: strange perf regression with data checksums |
Date: | 2025-05-19 19:45:01 |
Message-ID: | CAH2-Wzk69bmHD9YnpyHOkv=o=dzQ=SeYtMbcpaTXnRo-wnQ7NA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 19, 2025 at 3:37 PM Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2025-05-19 20:17:16 | Re: strange perf regression with data checksums |
Previous Message | Andres Freund | 2025-05-19 19:37:14 | Re: strange perf regression with data checksums |