Re: strange perf regression with data checksums
От | Andres Freund |
---|---|
Тема | Re: strange perf regression with data checksums |
Дата | |
Msg-id | lbt2lqnbh5thcamt5zxpolmu35wg3coa5i523gpvqip3bsj7gw@4s4n4upizbo4 обсуждение исходный текст |
Ответ на | Re: strange perf regression with data checksums (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
Hi, On 2025-05-19 15:45:01 -0400, Peter Geoghegan wrote: > 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. I'm not against that - ISTM we should do both. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: