At Wed, 7 Dec 2016 13:26:38 +0900, Michael Paquier <michael.paqu...@gmail.com> wrote in <CAB7nPqSyfsg=gHeqgXyzP0iGWvdyrXqnG-UENzfueaU=2m5...@mail.gmail.com> > On Wed, Dec 7, 2016 at 12:32 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > > So, isn't it better to compare the performance of some algorithms and > > confirm which is the best for quorum commit? Since this code is hot, i.e., > > can be very frequently executed, I'd like to avoid waste of cycle as much > > as possible. > > It seems to me that it would be simple enough to write a script to do > that to avoid any other noise: allocate an array with N random > elements, and fetch the M-th element from it after applying a sort > method. I highly doubt that you'd see much difference with a low > number of elements, now if you scale at a thousand standbys in a > quorum set you may surely see something :*) > Anybody willing to try out?
Aside from measurement of the two sorting methods, I'd like to point out that quorum commit basically doesn't need sorting. Counting comforming santdbys while scanning the walsender(receiver) LSN list comparing with the target LSN is O(n). Small refactoring of SyncRerpGetOldestSyncRecPtr would enough to do that. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
