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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
