Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGpVE-00074f-Bj for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Nov 2017 17:05:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eGpVD-00081E-UP for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Nov 2017 17:04:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eGpVD-000814-P7 for pgsql-hackers@lists.postgresql.org; Mon, 20 Nov 2017 17:04:59 +0000 Received: from mx2.mailbox.org ([80.241.60.215]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eGpVA-0004I8-2A for pgsql-hackers@postgresql.org; Mon, 20 Nov 2017 17:04:59 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id A0E454CB18; Mon, 20 Nov 2017 18:04:53 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id hK1Zlt34FJMv; Mon, 20 Nov 2017 18:04:51 +0100 (CET) From: Antonin Houska To: Robert Haas cc: Tatsuro Yamada , "pgsql-hackers@postgresql.org" Subject: Re: [HACKERS] CLUSTER command progress monitor In-reply-to: References: <59A77072.3090401@lab.ntt.co.jp> Comments: In-reply-to Robert Haas message dated "Fri, 08 Sep 2017 05:55:53 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Nov 2017 18:05:25 +0100 Message-ID: <15653.1511197525@localhost> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas wrote: > On Wed, Aug 30, 2017 at 10:12 PM, Tatsuro Yamada > wrote: > > 1. scanning heap > > 2. sort tuples >=20 > 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 th= at 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. --=20 Antonin Houska Cybertec Sch=C3=B6nig & Sch=C3=B6nig GmbH Gr=C3=B6hrm=C3=BChlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at