"Albe Laurenz" <laurenz.a...@wien.gv.at> wrote: > What if there is an index on the "ishighlander" row? > Then an index scan would find only one candidate to examine, > and the other rows would not even be touched by the execution plan. I assume you're talking about this line of your function: SELECT count(*) INTO n FROM scots WHERE ishighlander; I'm further assuming that you meant an index on the ishighlander *column*. I can think of more than one way to handle that. Off the top of my head, I think it would work to acquire an update lock on both old and new index entries for a row when it is updated, and to lock the range of an index used for a scan with the new SIREAD lock. Or perhaps, since the row must be visited to test visibility, the update lock could be on the old and new rows, and the index scan would find the conflict in that way. Or it could keep track of the various tuples which represent different mutations of a row, and link back from the "not visible to me" row which has been updated to true, and find that it is a mutation of a visible row. These are important implementation details to be worked out (very carefully!). I don't claim to have worked through all such details yet, or even to be familiar enough with the PostgreSQL internals to do so in a reasonable time. :-( -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers