Bonjour Michaël,
>> 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.
Hmmm. Progress is more an interactive feature where the previous result is
overriden thanks to the \r. 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 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.
I do not see why it would be better to do it roughly if it is already
implemented precisely and nicely.
>> 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...
I would prefer to have the speed simply printed out.
The per second or more thing is debatable, but for the other changes I do
not think that they improve the feature much.
As I said, I'm only a reviewer, you do as you feel.
--
Fabien.
