[HACKERS] Optimizing GetRunningTransactionLocks()
My list of things to do included optimising GetRunningTransactionLocks(), run once per checkpoint. I was thinking I needed to try harder to avoid acquiring LWlocks on all the lock partitions. ISTM that I don't need to do this - lwlocks on lock partitions are almost never contended now, so this should go much faster than before. Any thoughts? Do we think it would benefit from further tweaking? I'll assume not unless I hear from somebody with a different idea. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Optimizing GetRunningTransactionLocks()
Simon Riggs si...@2ndquadrant.com writes: My list of things to do included optimising GetRunningTransactionLocks(), run once per checkpoint. I was thinking I needed to try harder to avoid acquiring LWlocks on all the lock partitions. ISTM that I don't need to do this - lwlocks on lock partitions are almost never contended now, so this should go much faster than before. Any thoughts? Do we think it would benefit from further tweaking? I'll assume not unless I hear from somebody with a different idea. ISTM that some evidence of a problem should be acquired before expending sweat on a solution ... have you seen evidence that this creates any real issue? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
