From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimizing Read-Only Scalability |
Date: | 2009-05-14 18:06:40 |
Message-ID: | 603c8f070905141106q1f2e351dmac7cf66f00eadee0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 14, 2009 at 1:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, May 14, 2009 at 1:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Field | 2009-05-14 18:22:18 | Re: pg_views definition format |
Previous Message | Simon Riggs | 2009-05-14 17:59:21 | Re: Optimizing Read-Only Scalability |