On Fri, Sep 23, 2016 at 9:20 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Fri, Sep 23, 2016 at 6:50 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Sep 22, 2016 at 7:44 PM, Tomas Vondra >> <tomas.von...@2ndquadrant.com> wrote: >>> I don't dare to suggest rejecting the patch, but I don't see how we could >>> commit any of the patches at this point. So perhaps "returned with feedback" >>> and resubmitting in the next CF (along with analysis of improved workloads) >>> would be appropriate. >> >> I think it would be useful to have some kind of theoretical analysis >> of how much time we're spending waiting for various locks. So, for >> example, suppose we one run of these tests with various client counts >> - say, 1, 8, 16, 32, 64, 96, 128, 192, 256 - and we run "select >> wait_event from pg_stat_activity" once per second throughout the test. >> Then we see how many times we get each wait event, including NULL (no >> wait event). Now, from this, we can compute the approximate >> percentage of time we're spending waiting on CLogControlLock and every >> other lock, too, as well as the percentage of time we're not waiting >> for lock. That, it seems to me, would give us a pretty clear idea >> what the maximum benefit we could hope for from reducing contention on >> any given lock might be. >> > As mentioned earlier, such an activity makes sense, however today, > again reading this thread, I noticed that Dilip has already posted > some analysis of lock contention upthread [1]. It is clear that patch > has reduced LWLock contention from ~28% to ~4% (where the major > contributor was TransactionIdSetPageStatus which has reduced from ~53% > to ~3%). Isn't it inline with what you are looking for?
Hmm, yes. But it's a little hard to interpret what that means; I think the test I proposed in the quoted material above would provide clearer data. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
