Re: Unhappy about API changes in the no-fsm-for-small-rels patch

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Mon, May 6, 2019 at 8:57 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> On 2019-05-06 11:10:15 -0400, Robert Haas wrote:
>>> I think it's legitimate to question whether sending additional
>>> invalidation messages as part of the design of this feature is a good
>>> idea.

>> I don't think it's an actual problem. We'd only do so when creating an
>> FSM, or when freeing up additional space that'd otherwise not be visible
>> to other backends.

> The other place we need to consider for this is when one of the
> backends updates its map (due to unavailability of space in the
> existing set of pages). We can choose not to send invalidation in
> this case, but then different backends need to identify the same thing
> themselves and reconstruct the map again.

I'm inclined to wonder why bother with invals at all. The odds are
quite good that no other backend will care (which, I imagine, is the
reasoning behind why the original patch was designed like it was).
A table that has a lot of concurrent write activity on it is unlikely
to stay small enough to not have a FSM for long.

The approach I'm imagining here is not too different from Robert's
"just search the table's pages every time" straw-man. Backends would
cache the results of their own searches, but not communicate about it.

regards, tom lane