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. Of course, SetHintBits() would have to update the checksum too. But if it could determine where the hint bit is located in the buffer and if "some intermediate state" of the computation was maintained for each page in shared buffers, then the checksum update might be cheaper than the initial computation. But I'm not sure I understand the algorithm enough. -- Antonin Houska Web: https://www.cybertec-postgresql.com
