On Thu, Dec 17, 2015 at 11:03 AM, Aleksander Alekseev <a.aleks...@postgrespro.ru> wrote: >> It'd really like to see it being replaced by a queuing lock >> (i.e. lwlock) before we go there. And then maybe partition the >> freelist, and make nentries an atomic. > > I believe I just implemented something like this (see attachment). The > idea is to partition PROCLOCK hash table manually into NUM_LOCK_ > PARTITIONS smaller and non-partitioned hash tables. Since these tables > are non-partitioned spinlock is not used and there is no lock > contention.
Oh, that's an interesting idea. I guess the problem is that if the freelist is unshared, then users might get an error that the lock table is full when some other partition still has elements remaining. > On 60-core server we gain 3.5-4 more TPS according to benchmark > described above. As I understand there is no performance degradation in > other cases (different CPU, traditional pgbench, etc). 3.5-4 more TPS, or 3.5 times more TPS? Can you share the actual numbers? -- 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
