Re: Reducing relation locking overhead - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing relation locking overhead
Date
Msg-id 419.1133627383@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing relation locking overhead  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Esha Palta
Date:
Subject: unsubscribe
Next
From: Tom Lane
Date:
Subject: Re: Reducing relation locking overhead