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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
