At Tue, 20 Dec 2016 23:47:22 +0900, Fujii Masao <masao.fu...@gmail.com> wrote in <cahgqgwfcehv8bpp0hv2vq8kxahqmfn7pfagkkspyvip0fri...@mail.gmail.com> > On Tue, Dec 20, 2016 at 2:46 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: > > On Tue, Dec 20, 2016 at 2:31 PM, Masahiko Sawada <sawada.m...@gmail.com> > > wrote: > >> Do we need to consider the sorting method and the selecting k-th > >> latest LSN method? > > > > Honestly, nah. Tests are showing that there are many more bottlenecks > > before that with just memory allocation and parsing. > > I think that it's worth prototyping alternative algorithm, and > measuring the performances of those alternative and current > algorithms. This measurement should check not only the bottleneck > but also how much each algorithm increases the time that backends > need to wait for before they receive ack from walsender. > > If it's reported that current algorithm is enough "effecient", > we can just leave the code as it is. OTOH, if not, let's adopt > the alternative one.
I'm personally interested in the difference of them but it doesn't seem urgently required. If we have nothing particular to do with this, considering other ordering method would be valuable. By a not-well-grounded thought though, maintaining top-kth list by insertion sort would be promising rather than running top-kth sorting on the whole list. Sorting on all walsenders is needed for the first time and some other situation though. By the way, do we continue dispu^h^hcussing on the format of s_s_names and/or a successor right now? regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers