Re: Progress reporting for pg_verify_checksums
От | Michael Paquier |
---|---|
Тема | Re: Progress reporting for pg_verify_checksums |
Дата | |
Msg-id | 20190402021357.GJ16093@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Progress reporting for pg_verify_checksums (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Progress reporting for pg_verify_checksums
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: