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. Now, we could also try that experiment with various patches. If we can show that some patch reduces CLogControlLock contention without increasing TPS, they might still be worth committing for that reason. Otherwise, you could have a chicken-and-egg problem. If reducing contention on A doesn't help TPS because of lock B and visca-versa, then does that mean we can never commit any patch to reduce contention on either lock? Hopefully not. But I agree with you that there's certainly not enough evidence to commit any of these patches now. To my mind, these numbers aren't convincing. -- 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