From: Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: pg@bowt.ie, Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Subject: Re: [HACKERS] CLUSTER command progress monitor
Date: Mon, 3 Dec 2018 18:22:20 +0900
Message-ID: <bb3d3eb2-0464-34c0-e2cf-adab9d6c2a06@lab.ntt.co.jp> (raw)
In-Reply-To: <CA+q6zcXhoKfyeFxXvmfTGAn+t5H4gELBYjLLEYuFDbUQDjn+2g@mail.gmail.com>
References: <59A77072.3090401@lab.ntt.co.jp>
<CA+TgmobcMQEFvJkEqunpXfj2Uuc21Lt_0X_nJowd9CEebY15GQ@mail.gmail.com>
<59B5F6C0.1090008@lab.ntt.co.jp>
<CA+Tgmoa2Huap7teh5RPin+36++GbBKukoQgha5KDhJTJqKeF1g@mail.gmail.com>
<59B7D119.2000101@lab.ntt.co.jp>
<CA+TgmobNjKsg7t3PwDBjquYyrhBX1BeTsNEmAjfMKwEDz2ib3A@mail.gmail.com>
<CAH2-WzknWhguFqC17Ax512C2UwoHqAE14bsrE+S-Za9u8pDAyQ@mail.gmail.com>
<3ec1c97a-6293-237a-4e49-1b16a7a33273@lab.ntt.co.jp>
<CA+q6zcXhoKfyeFxXvmfTGAn+t5H4gELBYjLLEYuFDbUQDjn+2g@mail.gmail.com>
On 2018/11/29 21:20, Dmitry Dolgov wrote:
>> On Fri, Aug 24, 2018 at 7:06 AM Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp> wrote:
>>
>> On 2017/11/22 6:07, Peter Geoghegan wrote:
>>> On Mon, Oct 2, 2017 at 6:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> Progress reporting on sorts seems like a tricky problem to me, as I
>>>> said before. In most cases, a sort is going to involve an initial
>>>> stage where it reads all the input tuples and writes out quicksorted
>>>> runs, and then a merge phase where it merges all the output tapes into
>>>> a sorted result. There are some complexities; for example, if the
>>>> number of tapes is really large, then we might need multiple merge
>>>> phases, only the last of which will produce tuples.
>>>
>>> This would ordinarily be the point at which I'd say "but you're very
>>> unlikely to require multiple passes for an external sort these days".
>>> But I won't say that on this thread, because CLUSTER generally has
>>> unusually wide tuples, and so is much more likely to be I/O bound, to
>>> require multiple passes, etc. (I bet the v10 enhancements
>>> disproportionately improved CLUSTER performance.)
>>
>> Hi,
>>
>> I came back to develop the feature for community.
>> V4 patch is corrected these following points:
>>
>> - Rebase on master (143290efd)
>> - Fix document
>> - Replace the column name scan_index_relid with cluster_index_relid.
>> Thanks to Jeff Janes!
>>
>> I'm now working on improving the patch based on Robert's comment related to
>> "Seqscan and Sort case" and also considering how to handle the "Index scan case".
>
> Thank you,
>
> Unfortunately, this patch has some conflicts now, could you rebase it? Also
> what's is the status of your work on improving it based on the
> provided feedback?
>
> In the meantime I'm moving it to the next CF.
Thank you for managing the CF and Sorry for the late reply.
I'll rebase it for the next CF and also I'll clear my head because the patch
needs design change to address the feedbacks, I guess. Therefore, the status is
reconsidering the design of the patch. :)
Regards,
Tatsuro Yamada
NTT Open Source Software Center
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: yamada.tatsuro@lab.ntt.co.jp, 9erthalion6@gmail.com, robertmhaas@gmail.com, jeff.janes@gmail.com, thomas.munro@enterprisedb.com, michael.paquier@gmail.com
Subject: Re: [HACKERS] CLUSTER command progress monitor
In-Reply-To: <bb3d3eb2-0464-34c0-e2cf-adab9d6c2a06@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox