Kevin Grittner 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;
Right.
> I'm further assuming that you meant an index on the ishighlander
> *column*.
Of course. Sorry for the sloppiness.
> 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,
As far as I know, only the table rows that are found in the index scan
are examined for visibility. Which would be only one in my example.
> 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. :-(
Of course, and that is leading us too far. Thanks for your patience.
But in your attempt to sketch a way how true serializability could
be implemented, you went beyond the scope of the original paper,
which does not claim to tackle "phantoms".
I think the idea is promising, and it would be interesting to see
performance results for an implementation that covers predicates.
As you mentioned in your first post, there will not be a free lunch.
What hurts concurrency in an implementation with blocking read locks
might also hurt concurrency in an implementation where transactions
are frequently aborted and have to be retried.
Yours,
Laurenz Albe
