Re: Speed up transaction completion faster after many relations are accessed in a transaction - Mailing list pgsql-hackers
From | David Rowley |
---|---|
Subject | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
Date | |
Msg-id | CAApHDvry81SKSL3KQMuzg7eMTd-V+_DA=-K4QRte1Xz1=g0UrA@mail.gmail.com Whole thread Raw |
In response to | Re: Speed up transaction completion faster after many relations are accessed in a transaction (Zhihong Yu <zyu@yugabyte.com>) |
Responses |
Re: Speed up transaction completion faster after many relations are accessed in a transaction
|
List | pgsql-hackers |
On Sat, 1 Jan 2022 at 15:40, Zhihong Yu <zyu@yugabyte.com> wrote: > + locallock->nLocks -= locallockowner->nLocks; > + Assert(locallock->nLocks >= 0); > > I think the assertion is not needed since the above code is in if block : > > + if (locallockowner->nLocks < locallock->nLocks) > > the condition, locallock->nLocks >= 0, would always hold after the subtraction. That makes sense. I've removed the Assert in the attached patch. Thanks for looking at the patch I've also spent a bit more time on the patch. There were quite a few outdated comments remaining. Also, the PROCLOCK releaseMask field appears to no longer be needed. I also did a round of benchmarking on the attached patch using a very recent master. I've attached .sql files and the script I used to benchmark. With 1024 partitions, lock1.sql shows about a 4.75% performance increase. This would become larger with more partitions and less with fewer partitions. With the patch, lock2.sql about a 10% performance increase over master. lock3.sql does not seem to have changed much and lock4.sql shows a small regression with the patch of about 2.5%. I'm not quite sure how worried we should be about lock4.sql slowing down lightly. 2.5% is fairly small given how hard I'm exercising the locking code in that test. There's also nothing much to say that the slowdown is not just due to code alignment changes. I also understand that Amit L is working on another patch that will improve the situation for lock1.sql by not taking the locks on relations that will be run-time pruned at executor startup. I think it's still worth solving this regardless of Amit's patch as with current master we still have a situation where short fast queries which access a small number of tables can become slower once the backend has obtained a large number of locks concurrently and bloated the locallocktable. As for the patch. I feel it's a pretty invasive change to how we release locks and the resowner code. I'd be quite happy for some review of it. Here are the full results as output by the attached script. drowley@amd3990x:~$ echo master master drowley@amd3990x:~$ ./lockbench.sh lock1.sql tps = 38078.011433 (without initial connection time) tps = 38070.016792 (without initial connection time) tps = 39223.118769 (without initial connection time) tps = 37510.105287 (without initial connection time) tps = 38164.394128 (without initial connection time) lock2.sql tps = 247.963797 (without initial connection time) tps = 247.374174 (without initial connection time) tps = 248.412744 (without initial connection time) tps = 248.192629 (without initial connection time) tps = 248.503728 (without initial connection time) lock3.sql tps = 1162.937692 (without initial connection time) tps = 1160.968689 (without initial connection time) tps = 1166.908643 (without initial connection time) tps = 1160.288547 (without initial connection time) tps = 1160.336572 (without initial connection time) lock4.sql tps = 282.173560 (without initial connection time) tps = 284.470330 (without initial connection time) tps = 286.089644 (without initial connection time) tps = 285.548487 (without initial connection time) tps = 284.313505 (without initial connection time) drowley@amd3990x:~$ echo Patched Patched drowley@amd3990x:~$ ./lockbench.sh lock1.sql tps = 40338.975219 (without initial connection time) tps = 39803.433365 (without initial connection time) tps = 39504.824194 (without initial connection time) tps = 39843.422438 (without initial connection time) tps = 40624.483013 (without initial connection time) lock2.sql tps = 274.413309 (without initial connection time) tps = 271.978813 (without initial connection time) tps = 275.795091 (without initial connection time) tps = 273.628649 (without initial connection time) tps = 273.049977 (without initial connection time) lock3.sql tps = 1168.557054 (without initial connection time) tps = 1168.139469 (without initial connection time) tps = 1166.366440 (without initial connection time) tps = 1165.464214 (without initial connection time) tps = 1167.250809 (without initial connection time) lock4.sql tps = 274.842298 (without initial connection time) tps = 277.911394 (without initial connection time) tps = 278.702620 (without initial connection time) tps = 275.715606 (without initial connection time) tps = 278.816060 (without initial connection time) David
Attachment
pgsql-hackers by date: