Re: Progress reporting for pg_verify_checksums
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Michael Banck <michael.banck@credativ.de>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, alvherre@2ndquadrant.com, mailings@oopsware.de, thomas.munro@enterprisedb.com, pgsql-hackers@postgresql.org
Date: 2019-04-02T02:13:57Z
Lists: 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
Commits
-
Add progress reporting to pg_checksums
- 280e5f14056b 12.0 landed
-
Fix thinko when bumping on temporary directories in pg_verify_checksums
- da453004869d 11.3 landed
-
Fix thinko when bumping on temporary directories in pg_checksums
- 6eebfdc38b17 12.0 landed