On Fri, Jun 9, 2017 at 2:39 PM, Jim Van Fleet <vanfl...@us.ibm.com> wrote: > I left out the retry in LWLockAcquire.
If you want this to be considered, you should add it to the next CommitFest, currently https://commitfest.postgresql.org/14/ However, I can't see this being acceptable in the current form: 1. I'm pretty sure that there will be no appetite for introducing special cases for ProcArrayLock into lwlock.c directly; such logic should be handled by the code that calls lwlock.c. It's very unpalatable to have LWLockConditionalAcquire() harcoded to fail always for ProcArrayLock, and it's also adding overhead for every caller that reaches those "if" statements and has to branch or not. 2. Always using the group-clearing approach instead of only when the lock is uncontended seems like it will lead to a loss of performance in some situations. 3. This adds a good amount of complexity to the code but it's not clearly better overall. Your own results in http://postgr.es/m/ofbab24999.8db8c8de-on86258136.006aeb24-86258136.006b3...@notes.na.collabserv.com show that some workloads benefit and others are harmed. I don't think a 6% loss on single-socket machines is acceptable; there are still plenty of those out there. I don't think the idea of partitioning ProcArrayLock is necessarily bad -- Heikki tried it before -- but I don't think it's necessarily easy to work out all the kinks. -- 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
