From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SSI performance |
Date: | 2011-02-04 14:37:27 |
Message-ID: | AANLkTi=pnMFHYJ3=4D8K3bSz7-cB_4sncYmDsyz6yXFE@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 4, 2011 at 9:29 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Vitalii Tymchyshyn | 2011-02-04 14:38:30 | Re: [HACKERS] Slow count(*) again... |
Previous Message | Kenneth Marshall | 2011-02-04 14:33:15 | Re: [HACKERS] Slow count(*) again... |