Re: Reducing relation locking overhead

Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> What's worse, once you have excluded writes you have to rescan the entire
>> table to be sure you haven't missed anything.

> I was thinking you would set a flag to disable use of the FSM for
> inserts/updates while the reindex was running. So you would know where
> to find the new tuples, at the end of the table after the last tuple
> you read.

There are paths that do not consult the FSM, eg update where the new
tuple fits on the same page as the old, or where the backend has already
been given a target page by the FSM. And this "set a flag" idea in
itself has enormous costs, because the flag will become a central point
of contention: it *must* be touched by every single tuple insertion.

regards, tom lane