> This idea can improve the situation with ProcLock hash table, but I > think IIUC what Andres is suggesting would reduce the contention > around dynahash freelist and can be helpful in many more situations > including BufMapping locks.
I agree. But as I understand PostgreSQL community doesn't generally аpprоvе big changes that affects whole system. Especially if original problem was only in one particular place. Therefore for now I suggest only a small change. Naturally if it will be accepted there is no reason not to apply same changes for BufMapping or even dynahash itself with corresponding PROCLOCK hash refactoring. BTW could you (or anyone?) please help me find this thread regarding BufMapping or perhaps provide a benchmark? I would like to reproduce this issue but I can't find anything relevant in a mailing list. Also it seems to be a good idea to compare alternative approaches that were mentioned (atomics ops, group leader). Are there any discussions, benchmarks or patches regarding this topic? Frankly I have serious doubts regarding atomics ops since they will more likely create the same contention that a spinlock does. But perhaps there is a patch that works not the way I think it could work. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
