Re: Optimizing Read-Only Scalability - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Optimizing Read-Only Scalability
Date
Msg-id 603c8f070905141106q1f2e351dmac7cf66f00eadee0@mail.gmail.com
Whole thread Raw
In response to Re: Optimizing Read-Only Scalability  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Optimizing Read-Only Scalability  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Thu, May 14, 2009 at 1:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, May 14, 2009 at 1:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> GetSnapshotData doesn't take an exclusive lock.  Neither does start or
>>> end of a read-only transaction.  AFAIK there is no reason, and certainly
>>> no shred of experimental evidence, to think that ProcArrayLock
>>> contention is the bottleneck for read-only scenarios.
>
>> I think Simon's point was that it is O(n) rather than O(1), not that
>> it took an exclusive lock.
>
> I think my point was that there's no evidence that GetSnapshotData
> is where the scalability issue is.  Without some evidence there's no
> point in kluging it up.

Sure.  I don't think anyone was proposing to commit something without
first testing it.

Supposing that the patch can be shown to improve performance for
all-read-only workloads, and supposing further that the patch can be
shown to have no material negative impact on write-heavy workloads, it
would also be interesting to throw in a bit of scattered write traffic
and see whether that completely negates the benefit or not.

...Robert


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Optimizing Read-Only Scalability
Next
From: Simon Riggs
Date:
Subject: Re: Optimizing Read-Only Scalability