On Fri, Feb 4, 2011 at 9:29 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > The interesting thing is that CoarserLockCovers() accounts for 20% of the > overall CPU time, or 2/3 of the overhead. The logic of PredicateLockAcquire > is: > > 1. Check if we already have a lock on the tuple. > 2. Check if we already have a lock on the page. > 3. Check if we already have a lock on the relation. > > So if you're accessing a lot of rows, so that your lock is promoted to a > relation lock, you perform three hash table lookups on every > PredicateLockAcquire() call to notice that you already have the lock. > > I was going to put a note at the beginning of this mail saying upfront that > this is 9.2 materila, but it occurs to me that we could easily just reverse > the order of those tests. That would cut the overhead of the case where you > already have a relation lock by 2/3, but make the case where you already > have a tuple lock slower. Would that be a good tradeoff?
Not sure. How much benefit do we get from upgrading tuple locks to page locks? Should we just upgrade from tuple locks to full-relation locks? It also seems like there might be some benefit to caching the knowledge that we have a full-relation lock somewhere, so that once we get one we needn't keep checking that. Not sure if that actually makes sense... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
