From: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tatsuro Yamada <yamada.tatsuro@lab.ntt.co.jp>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] CLUSTER command progress monitor
Date: Mon, 20 Nov 2017 18:05:25 +0100
Message-ID: <15653.1511197525@localhost> (raw)
In-Reply-To: <CA+TgmobcMQEFvJkEqunpXfj2Uuc21Lt_0X_nJowd9CEebY15GQ@mail.gmail.com>
References: <59A77072.3090401@lab.ntt.co.jp>
<CA+TgmobcMQEFvJkEqunpXfj2Uuc21Lt_0X_nJowd9CEebY15GQ@mail.gmail.com>
Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Aug 30, 2017 at 10:12 PM, Tatsuro Yamada
> <yamada.tatsuro@lab.ntt.co.jp> wrote:
> > 1. scanning heap
> > 2. sort tuples
>
> These two phases overlap, though. I believe progress reporting for
> sorts is really hard. In the simple case where the data fits in
> work_mem, none of the work of the sort gets done until all the data is
> read. Once you switch to an external sort, you're writing batch
> files, so a lot of the work is now being done during data loading.
> But as the number of batch files grows, the final merge at the end
> becomes an increasingly noticeable part of the cost, and eventually
> you end up needing multiple merge passes. I think we need some smart
> way to report on sorts so that we can tell how much of the work has
> really been done, but I don't know how to do it.
Whatever complexity is hidden in the sort, cost_sort() should have taken it
into consideration when called via plan_cluster_use_sort(). Thus I think that
once we have both startup and total cost, the current progress of the sort
stage can be estimated from the current number of input and output
rows. Please remind me if my proposal appears to be too simplistic.
--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at
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: ah@cybertec.at, robertmhaas@gmail.com, yamada.tatsuro@lab.ntt.co.jp
Subject: Re: [HACKERS] CLUSTER command progress monitor
In-Reply-To: <15653.1511197525@localhost>
* 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