Re: pgbench progress report improvements

Dear Robert,

>> (1) ...
> I really don't think it's a good idea to change the default behavior. 
> We've had many discussions about how the overhead of gettimeofday() can 
> sometimes be surprisingly large; I don't think we should assume it's 
> guaranteed to be small in this case.
>
> Also, changing established defaults will annoy users who like to 
> present defaults; I don't see any reason to assume that your preferences 
> will be universal.  In doubtful cases we should favor leaving the 
> behavior the way it's been in previous releases, because 
> backward-compatibility is very desirable.

I argued in another mail precisely, with worst figures found on the net, 
about the relative overhead of gettimeofday as used by pgbench, which is 
also handling network traffic and waiting for the database to perform 
actual transactions. I do not thing that I'm "assuming", and I'm trying to 
argument with objective data.

Anyway, this particular behavior is preserved by the current version of 
the patch, so no worry. The additional gettimeofday is *not* perform under 
standard "silent" benchmarking, and the standard deviation of the latency 
is not measured, because it can't. It is however measured under --rate and 
--progress. It is necessary for rate because otherwise the computed 
latency is false. It is done for progress because if you are interested to 
know what is going on, I assume that it would make sense to provide this 
data.

I must admit that I think, un-universaly, that people should care to know 
that their transaction latency can vary by several order of magnitudes, 
but this opinion is clearly not shared.

>> I tried to preserve the row-counting behavior because I thought that 
>> someone would object otherwise, but I would be really in favor of 
>> dropping the row-counting report behavior altogether and only keep the 
>> time triggered report.

> -1 for changing this again.
> Frankly, I might have come down in a different place if I had understood 
> exactly how this was going to end up being committed; it ended up being 
> quite different from what I was expecting.  But I really think that 
> relitigating this just so we can break backward compatibility again one 
> release later is not a good use of anyone's time, or a good idea in 
> general.

The current status on my small (SSD) laptop is that "pgbench -i" throws 
about 10 lines of 100,000-rows progress report per second. I must be a 
slow reader because I can't read that fast. So either other users can read 
much faster than me, or they have slower computers:-)

ISTM that it is no big deal to change this kind of thing on a minor 
contrib tool of postgresql if it is reasonnably better and useful, and I 
would be surprise and seeing protests about changing an unreadable flow to 
a readable one.

Anyway, let us keep this default behavior, as I hope there must be people 
who like it. Well, if anyone could tell me that he/she likes better having 
10 lines a second thrown on the screen than a regular progress report 
every few seconds, I would feel less stupid at reinstating this behavior 
and re-submitting a new version of the patch.

-- 
Fabien.