On Thu, Jan 18, 2024 at 12:15 PM Peter Geoghegan <p...@bowt.ie> wrote: > It's not okay if you fail to update the FSM a second time in the > second heap pass -- at least in some cases. It's reasonably frequent > for a page that has 0 usable free space when lazy_scan_prune returns > to go on to have almost BLCKSZ free space once lazy_vacuum_heap_page() > is done with it.
Oh, good point. That's an important subtlety I had missed. > That's a part of the problem too, I guess. > > The actual available free space on each page is literally changing all > the time, when measured at FSM_CATEGORIES-wise granularity -- which > leads to a mad dash among backends that all need the same amount of > free space for their new tuple. One reason why other systems pretty > much require coarse-grained increments of free space is the need to > manage the WAL overhead for a crash-safe FSM/free list structure. Interesting. -- Robert Haas EDB: http://www.enterprisedb.com
