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.
