From: david@lang.hm
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Jignesh K. Shah <J.K.Shah@sun.com>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Fri, 13 Mar 2009 21:29:24 -0700 (PDT)
Message-ID: <alpine.DEB.1.10.0903132124470.6196@asgard> (raw)
In-Reply-To: <49BA5960.EE98.0025.0@wicourts.gov>
References: <alpine.GSO.2.01.0903121613270.1925@westnet.com>
<C5DED7A7.33B2%scott@richrelevance.com>
<603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com>
<603c8f070903121829r31cf1472ha9876e5c480a542e@mail.gmail.com>
<12292.1236964604@sss.pgh.pa.us>
<49BA5960.EE98.0025.0@wicourts.gov>
On Fri, 13 Mar 2009, Kevin Grittner wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> I think that changing the locking behavior is attacking the problem
>>> at the wrong level anyway.
>>
>> Right. By the time a patch here could have any effect, you've
>> already lost the game --- having to deschedule and reschedule a
>> process is a large cost compared to the typical lock hold time for
>> most LWLocks. So it would be better to look at how to avoid
>> blocking in the first place.
>
> That's what motivated my request for a profile of the "80 clients with
> zero wait" case. If all data access is in RAM, why can't 80 processes
> keep 64 threads (on 8 processors) busy? Does anybody else think
> that's an interesting question, or am I off in left field here?
I don't think that anyone is arguing that it's not intersting, but I also
think that complete dismissal of the existing test case is also wrong.
last night Tom documented some reasons why the prior test may have some
issues, but even with those I think the test shows that there is room for
improvement on the locking.
making sure that the locking change doesn't cause problems for other
workload is a _very_ valid concern, but it's grounds for more testing, not
dismissal.
I think that the suggestion to wake up the first N waiters instead of all
of them is a good optimization (and waking N - # active back-ends would be
even better if there is an easy way to know that number) but I think that
it's worth making the result testable by more people so that we can see if
what workloads are pathalogical for this change (if any)
David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: david@lang.hm, Kevin.Grittner@wicourts.gov, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, gsmith@gregsmith.com, scott@richrelevance.com, J.K.Shah@sun.com
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <alpine.DEB.1.10.0903132124470.6196@asgard>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox