Re: strange perf regression with data checksums
От | Peter Geoghegan |
---|---|
Тема | Re: strange perf regression with data checksums |
Дата | |
Msg-id | CAH2-Wzk69bmHD9YnpyHOkv=o=dzQ=SeYtMbcpaTXnRo-wnQ7NA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: strange perf regression with data checksums (Aleksander Alekseev <aleksander@timescale.com>) |
Ответы |
Re: strange perf regression with data checksums
|
Список | 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 по дате отправления: