Dan Ports wrote:
> The obvious solution to me is to just keep the lock on both the old
> and new page.
That's the creative thinking I was failing to do. Keeping the old
lock will generate some false positives, but it will be rare and
those don't compromise correctness -- they just carry the cost of
starting the transaction over. In exchange you buy a savings in
predicate lock acquisition. In particular, by dodging LW locking for
a large percentage of calls, you help scalability. It can't cause
false negatives, so correctness is OK -- it's all about net costs.
> I was going to bemoan the extra complexity this would add -- but
> actually, couldn't we just replace PredicateLockPageCombine with a
> call to PredicateLockPageSplit since they'd now do the same thing?
I'd be inclined to leave the external interface alone, in case we
conceive of an even better implementation. We can just remove the
removeOld bool from the parameter list of the static
TransferPredicateLocksToNewTarget function, and keep the behavior
from the "false" case.
-Kevin
