On Tue, Aug 17, 2021 at 6:11 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Again, it's all about *systemic* effects. A FSM request is basically a
> choice *among* blocks that could in principle satisfy the request --
> often the number of basically-satisfactory blocks is huge (way too
> large, even). You have to bear in mind that concurrent requests are in
> competition with each other in much of the time. They are usually all
> looking for exactly the same thing (e.g., same free space
> requirement), or close to the same thing -- tuples within a given
> table tend to all be about as wide as each other.
>
> I can clearly sometimes see very high contention cases, where backends
> do way too much spinning inside the RelationGetBufferForTuple() loop.
> They're all more or less chasing the same scraps of free space, in a
> highly inefficient way. Even though there is probably an abundance of
> free space. Right now the heap pages that have the most free space are
> also the ones that are least likely to be used.
>
> Though I think that these backends should cooperate more, some amount
> of competition is probably necessary. If FSM_CATEGORIES used 3 bits
> instead of 8, then the backends could fall back on caring about some
> other thing that distinguished heap pages from each other that
> actually matters. Leading to less contention, and maybe better space
> utilization.
To me, it feels like the real issue here is that the free space map is
completely deterministic. As it's currently designed, you can reduce
the number of bits as much as you want, and it doesn't change
anything. Concurrent requests get the same answer, which is not what
we want. Just as a thought experiment, imagine that backends
preferentially prefer pages whose block numbers are congruent to their
PID module some integer. Now you have a reason - perhaps not the best
possible reason, but *a* reason - for every single backend to pounce
on the same target page.
--
Robert Haas
EDB: http://www.enterprisedb.com