On Wed, Aug 30, 2017 at 2:43 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jul 4, 2017 at 12:33 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> I have updated the patch to support wait events and moved it to upcoming CF. > > This patch doesn't apply any more, but I made it apply with a hammer > and then did a little benchmarking (scylla, EDB server, Intel Xeon > E5-2695 v3 @ 2.30GHz, 2 sockets, 14 cores/socket, 2 threads/core). > The results were not impressive. There's basically no clog contention > to remove, so the patch just doesn't really do anything. >
Yeah, in such a case patch won't help. > For example, > here's a wait event profile with master and using Ashutosh's test > script with 5 savepoints: > > 1 Lock | tuple > 2 IO | SLRUSync > 5 LWLock | wal_insert > 5 LWLock | XidGenLock > 9 IO | DataFileRead > 12 LWLock | lock_manager > 16 IO | SLRURead > 20 LWLock | CLogControlLock > 97 LWLock | buffer_content > 216 Lock | transactionid > 237 LWLock | ProcArrayLock > 1238 IPC | ProcArrayGroupUpdate > 2266 Client | ClientRead > > This is just a 5-minute test; maybe things would change if we ran it > for longer, but if only 0.5% of the samples are blocked on > CLogControlLock without the patch, obviously the patch can't help > much. I did some other experiments too, but I won't bother > summarizing the results here because they're basically boring. I > guess I should have used a bigger machine. > That would have been better. In any case, will do the tests on some higher end machine and will share the results. > Given that we've changed the approach here somewhat, I think we need > to validate that we're still seeing a substantial reduction in > CLogControlLock contention on big machines. > Sure will do so. In the meantime, I have rebased the patch. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
group_update_clog_v14.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers