On 11 January 2016 at 23:11, Stas Kelvich <s.kelv...@postgrespro.ru> wrote:
> > > > On 11 Jan 2016, at 21:43, Simon Riggs <si...@2ndquadrant.com> wrote: > > > > Have you measured lwlocking as a problem? > > > > Yes. GXACT locks that wasn’t even in perf top 10 on dual Xeon moves to the > first places when running on 60 core system. But Jesper’s flame graph on 24 > core system shows different picture. I think we can use a shmem hash table to identify the GID by name during LockGxact and avoid duplicates during prepare. Hashing on the first 16 bytes of the GID should be sufficient in most cases; the worst case would be the same as it is now, all depending on how people use the GID name field. The hash value can be calculated outside of the lock. We can also partition the lock without risk, just adds a little extra code. We can also optimize final removal (sketch of how to do that attached). -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2pc_remove_prepXacts.v1.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
