Re: Progress reporting for pg_verify_checksums

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-04-01 17:26:00
Message-ID: alpine.DEB.2.21.1904011918010.10594@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-04-01 17:34:45 Re: speeding up planning with partitions
Previous Message Andres Freund 2019-04-01 17:06:58 Re: Extending USE_MODULE_DB to more test suite types