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  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Progress reporting for pg_verify_checksums
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] generated columns