From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Staale Smedseng <Staale(dot)Smedseng(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Why are we waiting? |
Date: | 2008-02-06 20:01:46 |
Message-ID: | 16158.1202328106@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2008-02-06 at 14:42 -0500, Tom Lane wrote:
>> Not really, considering the extremely limited use of LW_SHARED in lock.c
>> (GetLockConflicts is used only by CREATE INDEX CONCURRENTLY, and
>> GetLockStatusData only by the pg_locks view). For the type of benchmark
>> that I gather this is, there should be *zero* LW_SHARED acquisitions at
>> all. And even if there are some, they could only be blocking against
>> the (undoubtedly much more frequent) LW_EXCLUSIVE acquisitions; it's not
>> very credible that there is zero contention among the LW_EXCLUSIVE locks
>> yet a few shared acquirers manage to get burnt.
> ...but the total wait time on those lock waits was 24 microseconds. I
> hardly call that burnt.
What you are failing to grasp is that the data is simply not credible
(unless perhaps Staale fesses up that his benchmark includes a whole lot
of pg_locks monitoring, in which case I'd want to see it redone without
anyway).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-02-06 20:35:54 | Re: PostgreSQL 8.4 development plan |
Previous Message | Tom Lane | 2008-02-06 19:58:07 | Re: Page-at-a-time Locking Considerations |