On Wed, Dec 21, 2016 at 10:39 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> 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.
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