Re: pgbench progress report improvements

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stěhule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: pgbench progress report improvements
Date: 2013-09-24 19:47:11
Message-ID: alpine.DEB.2.02.1309242044050.8198@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2013-09-24 19:57:20 Re: FW: REVIEW: Allow formatting in log_line_prefix
Previous Message Stephen Frost 2013-09-24 19:22:49 Re: record identical operator