On Wed, Dec 21, 2016 at 10:39 AM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > 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.
Yes, it's not urgent task. > 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? Yes. If there is better approach, we should discuss that. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
