Re: Emit fewer vacuum records by reaping removable tuples during pruning - Mailing list pgsql-hackers

On Thu, Jan 18, 2024 at 12:15 PM Peter Geoghegan <pg@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