Re: The Free Space Map: Problems and Opportunities

On Wed, Aug 18, 2021 at 7:36 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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.

I agree. Though note the separate problem with FSM_CATEGORIES that I
mentioned to Andres: if you want to maintain the FSM value for pages
eagerly within backends, then practically speaking a far lower
FSM_CATEGORIES-like constant seems necessary.

I'm really just saying that the fine granularity seems to me to be
basically the wrong approach. In general the single most important
thing is the amount of free space available -- we agree on that.
However, the only reason to remember very small *differences* in free
space between heap pages is because you intend to do *something* with
that extra information. But caring about noise-level differences seems
inherently bad -- there is bound to be a better fall-back behavior
that reduces contention, and actually *increases* space utilization in
practice (even though theoretically coarser-grained information might
hurt utilization a little).

> 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.

I agree that reducing FSM_CATEGORIES alone will not buy us anything.

--
Peter Geoghegan