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

From Michael Paquier
Subject Re: Progress reporting for pg_verify_checksums
Date
Msg-id 20190402021357.GJ16093@paquier.xyz
Whole thread Raw
In response to Re: Progress reporting for pg_verify_checksums  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Progress reporting for pg_verify_checksums
List pgsql-hackers
On Mon, Apr 01, 2019 at 07:26:00PM +0200, Fabien COELHO wrote:
> Hmmm. Progress is more an interactive feature where the previous result is
> overriden thanks to the \r.

Well, many people also redirect the output for such things.

> 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 cannot say for pgbench.  I personally think that's a lot but you are
the one who wrote it as such I guess.

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

Simple things can be extended later on, while complicated things
cannot, and we don't have similar metrics for other tools which may
make sense for them to have (not pg_rewind, but pg_basebackup).
Please note that progress reports on the backend also include total
amount of data to process vs current amount of data processed, which
is reliable output.  The speed may be nice, but it is easy enough to
see in an output file where things get stuck even if there is no
speed showing up (or maybe just the difference with the last progress
makes more sense to have?).
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Progress reporting for pg_verify_checksums
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] generated columns