Re: Progress reporting for pg_verify_checksums

Bonjour Michaël,

>> I do not think that it matters. I like to see things moving, and the
>> performance impact is null.
>
> Another point is that this bloats the logs redirected to a file by 4
> compared to the initial proposal.  I am not sure that this helps
> much for anybody.

Hmmm. Progress is more an interactive feature where the previous result is 
overriden thanks to the \r. Maybe it should be -P X where X is the 
expected delay in seconds. Pgbench progress reporting on initialization 
basically outputs 10 rows per second, probably it is too much.

>> 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.
>
> Let's revisit that when the need shows up then.  I'd rather have us
> start with a basic set of metrics which can be extended later on.

I do not see why it would be better to do it roughly if it is already 
implemented precisely and nicely.

>> 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.
>
> Well, with some progress generated once per second you are one
> substraction away to guess how much has been computed in the last N
> second...

I would prefer to have the speed simply printed out.

The per second or more thing is debatable, but for the other changes I do 
not think that they improve the feature much.

As I said, I'm only a reviewer, you do as you feel.

-- 
Fabien.