From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
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-01 06:57:52 |
Message-ID: | 20190401065752.GB16093@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 30, 2019 at 06:52:56PM +0100, Fabien COELHO wrote:
> I do not think that it matters. I like to see things moving, and the
> performance impact is null.
Another point is that this bloats the logs redirected to a file by 4
compared to the initial proposal. I am not sure that this helps
much for anybody.
> I do not think that it is a good idea, because Michael is thinking of adding
> some throttling capability, which would be a very good thing, but which will
> need something precise, so better use the precise stuff from the start.
> Also, the per second stuff induces rounding effects at the beginning.
Let's revisit that when the need shows up then. I'd rather have us
start with a basic set of metrics which can be extended later on.
> Hmmm. I like this information because I this is where I have expectations,
> whereas I'm not sure whether 1234 seconds for 12.3 GB is good or bad, but I
> know that 10 MB/s on my SSD is not very good.
Well, with some progress generated once per second you are one
substraction away to guess how much has been computed in the last N
second...
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2019-04-01 06:59:19 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
Previous Message | Surafel Temesgen | 2019-04-01 06:57:41 | Re: Re: FETCH FIRST clause WITH TIES option |