Antonin Houska <a...@cybertec.at> wrote: > Andres Freund <and...@anarazel.de> wrote: > > > What I'd instead like to propose is to implement the right to set hint bits > > as > > a bit in each buffer's state, similar to BM_IO_IN_PROGRESS. Tentatively I > > named this BM_SETTING_HINTS. It's only allowed to set BM_SETTING_HINTS when > > BM_IO_IN_PROGRESS isn't already set and StartBufferIO has to wait for > > BM_SETTING_HINTS to be unset to start IO. > > > > Naively implementing this, by acquiring and releasing the permission to set > > hint bits in SetHintBits() unfortunately leads to a significant performance > > regression. While the performance is unaffected for OLTPish workloads like > > pgbench (both read and write), sequential scans of unhinted tables regress > > significantly, due to the per-tuple lock acquisition this would imply. > > An alternative approach: introduce a flag that tells that the checksum is > being computed, and disallow setting hint bits when that flag is set. As long > as the checksum computation takes take much less time than the IO, fewer hint > bit updates should be rejected.
Well, the checksum actually should not be computed during the IO, so the IO would still disallow hint bit updates :-( -- Antonin Houska Web: https://www.cybertec-postgresql.com
