From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
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 17:52:56 |
Message-ID: | alpine.DEB.2.21.1903301845420.29753@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bonjour Michaël,
> 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.
I do not think that it matters. I like to see things moving, and the
performance impact is null.
> 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/.
I do not think that it is a good idea, because Michael is thinking of
adding some throttling capability, which would be a very good thing, but
which will need something precise, so better use the precise stuff from
the start. Also, the per second stuff induces rounding effects at the
beginning.
> A second thing is that I don't think that the speed is much useful.
Hmmm. I like this information because I this is where I have expectations,
whereas I'm not sure whether 1234 seconds for 12.3 GB is good or bad, but
I know that 10 MB/s on my SSD is not very good.
> 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.
Hmmm. That is life, I'd say I'm used to it.
> 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.
I would prefer that you would keep the patch with the initial precision &
features for the reasons outlined above, but you are the committer and I'm
only a reviewer.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-03-30 19:19:57 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
Previous Message | Julien Rouhaud | 2019-03-30 17:15:11 | Re: Checksum errors in pg_stat_database |