From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, alvherre(at)2ndquadrant(dot)com, mailings(at)oopsware(dot)de, thomas(dot)munro(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Progress reporting for pg_verify_checksums |
Date: | 2019-03-30 14:31:09 |
Message-ID: | 20190330143109.GC28827@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 28, 2019 at 03:53:59PM +0100, Fabien COELHO wrote:
> I think that it is good to show the overall impact of the signal stuff, in
> particular the fact that the size must always be computed if the progress
> may be activated.
Getting to know the total size and the current size are the two
important factors that matter when it comes to do progress reporting
in my opinion. I have read the patch, and I am not really convinced
by the need to show the progress report based on an interval of 250ms
as we talk about an operation which could take dozens of minutes. So
I have simplified the patch to only show a progress report every
second. This also removes the include for the time-related APIs from
portability/. A second thing is that I don't think that the speed is
much useful. I would expect the speed to be steady, still there is a
risk to show incorrect information if the speed of the operation is
spiky or irregular leading to an incorrect estimation of the remaining
time.
In short, I would like to commit the first patch as attached, which is
much more simple than what has been sent previously, still it provides
the progress information which is useful.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
checksums-progress-report.patch | text/x-diff | 7.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2019-03-30 14:57:31 | Re: Checksum errors in pg_stat_database |
Previous Message | Tom Lane | 2019-03-30 14:26:06 | Re: Column lookup in a row performance |