Re: foreign key locks

Patch v19 contains some tweaks. Most notably,

1. if an Xid requests a lock A, and then a lock B which is stronger than
A, then record only lock B and forget lock A. This is important for
performance, because EvalPlanQual obtains ForUpdate locks on the tuples
that it chases on an update chain. If EPQ was called by an update or
delete, previously a MultiXact was being created.

In a stock pgbench run this was causing lots of multis to be created,
even when there are no FKs.

This was most likely involved in the 9% performance decrease that was
previously reported.

2. Save a few TransactionIdIsInProgress calls in MultiXactIdWait. We
were calling it to determine how many transactions were still running,
but not all callers were interested in that info. XidIsInProgress is
not particularly cheap, so it seems good to skip it if possible. I
didn't try to measure the difference, however.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services