Re: Progress reporting for pg_verify_checksums
От | Fabien COELHO |
---|---|
Тема | Re: Progress reporting for pg_verify_checksums |
Дата | |
Msg-id | alpine.DEB.2.21.1903301845420.29753@lancre обсуждение исходный текст |
Ответ на | Re: Progress reporting for pg_verify_checksums (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Progress reporting for pg_verify_checksums
|
Список | pgsql-hackers |
Bonjour Michaël, > Getting to know the total size and the current size are the two > important factors that matter when it comes to do progress reporting > in my opinion. I have read the patch, and I am not really convinced > by the need to show the progress report based on an interval of 250ms > as we talk about an operation which could take dozens of minutes. I do not think that it matters. I like to see things moving, and the performance impact is null. > So I have simplified the patch to only show a progress report every > second. This also removes the include for the time-related APIs from > portability/. 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. > A second thing is that I don't think that the speed is much useful. 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. > I would expect the speed to be steady, still there is a risk to show > incorrect information if the speed of the operation is spiky or > irregular leading to an incorrect estimation of the remaining time. Hmmm. That is life, I'd say I'm used to it. > In short, I would like to commit the first patch as attached, which is > much more simple than what has been sent previously, still it provides > the progress information which is useful. I would prefer that you would keep the patch with the initial precision & features for the reasons outlined above, but you are the committer and I'm only a reviewer. -- Fabien.
В списке pgsql-hackers по дате отправления: