Re: Speed up transaction completion faster after many relations are accessed in a transaction
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, "Imai, Yoshikazu" <imai.yoshikazu@jp.fujitsu.com>,
Andres Freund <andres@anarazel.de>, Simon Riggs <simon@2ndquadrant.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2019-07-23T06:11:51Z
Lists: pgsql-hackers
Attachments
- shrink_bloated_locallocktable_v7.patch (application/octet-stream) patch v7
On Tue, 23 Jul 2019 at 15:47, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > OTOH, how about my original patch that is based on the local lock list? I expect that it won't that significant slowdown in the same test case. If it's not satisfactory, then v6 is the best to commit. I think we need to move beyond the versions that have been reviewed and rejected. I don't think the reasons for their rejection will have changed. I've attached v7, which really is v6 with some comments adjusted and the order of the hash_get_num_entries and hash_get_max_bucket function calls swapped. I think hash_get_num_entries() will return 0 most of the time where we're calling it, so it makes sense to put the condition that's less likely to be true first in the if condition. I'm pretty happy with v7 now. If anyone has any objections to it, please speak up very soon. Otherwise, I plan to push it about this time tomorrow. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Reorder LOCALLOCK structure members to compact the size
- 28988a84cf19 12.0 landed
-
Be more careful to not lose sync in the FE/BE protocol.
- 2b3a8b20c2da 9.5.0 cited