Re: Progress reporting for pg_verify_checksums - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Progress reporting for pg_verify_checksums
Date
Msg-id alpine.DEB.2.21.1903301845420.29753@lancre
Whole thread Raw
In response to Re: Progress reporting for pg_verify_checksums  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Progress reporting for pg_verify_checksums
List 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.

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Checksum errors in pg_stat_database
Next
From: Peter Geoghegan
Date:
Subject: Re: pgsql: Compute XID horizon for page level index vacuum on primary.