On Wed, Dec 21, 2016 at 10:39 AM, Kyotaro HORIGUCHI
> 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
> 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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: