| 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-02 06:11:45 |
| Message-ID: | alpine.DEB.2.21.1904020805030.10740@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bonjour Michaël,
>> 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.
Nope, this was way before I intervened. ISTM that a patch was submitted to
get per second or slower progress reporting on the initalization, and it
was rejected. Now that there are many SSD, maybe I could bring it back. An
issue with pbbench is that the reported time and progress is for the
insertion phase only, but PK and other FK declaration take as much time
and are not included, so I'm not sure it can be much better.
For pg_checksums, probably some improvement patch will be submitted later,
if someone feels like it.
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Darafei Komяpa Praliaskouski | 2019-04-02 06:34:14 | Re: Compressed TOAST Slicing |
| Previous Message | Haribabu Kommi | 2019-04-02 06:11:07 | Re: Pluggable Storage - Andres's take |