On Fri, Feb 4, 2011 at 9:29 AM, Heikki Linnakangas
<heikki.linnakangas@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