Re: Problems with the FSM, heap fillfactor, and temporal locality

On Wed, Aug 26, 2020 at 1:46 AM John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> wrote:
> The fact that that logic extends by 20 * numwaiters to get optimal
> performance is a red flag that resources aren't being allocated
> efficiently.

I agree that that's pretty suspicious.

> I have an idea to ignore fp_next_slot entirely if we have
> extended by multiple blocks: The backend that does the extension
> stores in the FSM root page 1) the number of blocks added and 2) the
> end-most block number. Any request for space will look for a valid
> value here first before doing the usual search. If there is then the
> block to try is based on a hash of the xid. Something like:
>
> candidate-block = prev-end-of-relation + 1 + (xid % (num-new-blocks))

I was thinking of doing something in shared memory, and not using the
FSM here at all. If we're really giving 20 pages out to each backend,
we will probably benefit from explicitly assigning contiguous ranges
of pages to each backend, and making some effort to respect that they
own the blocks in some general sense. Hopefully without also losing
access to the free space in corner cases (e.g. one of the backend's
has an error shortly after receiving its contiguous range of blocks).

> To guard against collisions, then peak in the FSM at that slot and if
> it's not completely empty, then search FSM using a "look-nearby" API
> and increment a counter every time we collide. When the counter gets
> to some-value, clear the special area in the root page so that future
> backends use the usual search.

The backends already use a look nearby API, sort of --
RecordAndGetPageWithFreeSpace() already behaves that way. I'm not sure
exactly how well it works in practice, but it definitely works to some
degree.

> Also num-new-blocks above could be scaled down from the actual number
> of blocks added, just to make sure writes aren't happening all over
> the place.

Or scaled up, perhaps.

--
Peter Geoghegan