At Tue, 20 Dec 2016 23:47:22 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in
<CAHGQGwFcEhv8BPP0HV2VQ8kXaHQmfN7PFAgkKsPyVip0frizpg@mail.gmail.com>
> On Tue, Dec 20, 2016 at 2:46 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Tue, Dec 20, 2016 at 2:31 PM, Masahiko Sawada <sawada.mshk@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
