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

Hi,

On 2019-05-06 11:10:15 -0400, Robert Haas wrote:
> I'm really surprised that the original design of this patch involved
> storing state in global variables.  That seems like a pretty poor
> decision.  This is properly per-relation information, and any approach
> like that isn't going to work well when there are multiple relations
> involved, unless the information is only being used for a single
> attempt to find a free page, in which case it should use parameters
> and function-local variables, not globals.

I'm was too.


> I think it's legitimate to question whether sending additional
> invalidation messages as part of the design of this feature is a good
> idea.  If it happens frequently, it could trigger expensive sinval
> resets more often.  I don't understand the various proposals well
> enough to know whether that's really a problem, but if you've got a
> lot of relations for which this optimization is in use, I'm not sure I
> see why it couldn't be.

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 alternative to sinval would thus be a) not
discovering there's free space and extending the relation b) checking
disk state for a new FSM all the time. Which are much more expensive.


> I think at some point it was proposed that, since an FSM access
> involves touching 3 blocks, it ought to be fine for any relation of 4
> or fewer blocks to just check all the others.  I don't really
> understand why we drifted off that design principle, because it seems
> like a reasonable theory.  Such an approach doesn't require anything
> in the relcache, any global variables, or an every-other-page
> algorithm.

It's not that cheap to touch three heap blocks every time a new target
page is needed. Requires determining at least the target relation size
or the existance of the FSM fork.

We'll also commonly *not* end up touching 3 blocks in the FSM -
especially when there's actually no free space. And the FSM contents are
much less contended than the heap pages - the hot paths don't update the
FSM, and if so, the exclusive locks are held for a very short time only.

Greetings,

Andres Freund