Re: pgbench progress report improvements - split 3 v2 - A

>>> Patch (2): Make --initialize mode respect --progress.
>>> Rejected
>>
>> I missed this one...
>
> See the second half of this message, including quoted material:
> http://www.postgresql.org/message-id/CA+TgmoZNXkm-EtszHX=KWq34H5Ni4CS8DG31no86cmDryAqZ_w@mail.gmail.com

I did not read Peter Haas comments as whether --progress should be used
for both modes, although it is in the section about it.

All his argumentation is about *not changing any defaults*. I understood
that his "-1" applied about the dropping the row-counting based reporting:
Robert complains about any "break[ing] backward compatibility again one
release later" in the paragraph, not really about --progress becoming
significant under -i, so this would be a veto agains what you called
"Patch (1)".

So what I've done in version 5 of the patch on this subject is that
--progress specifies the interval of the progress report in any mode, and
quiet just set it to five seconds for initialization as is the current
behavior. Version 5 does not change any current default behavior, as I
understood that this was the requirement expressed by Robert Haas.

>>> Patch (5): Take thread start time at the beginning of the thread.
>>> Returned with Feedback
>>
>> Hmmm. I fought back on the feedback:-) I thought my arguments where
>> good enough to consider an accept.
>
> Here is the feedback in question:
> http://www.postgresql.org/message-id/20130930223621.GA125986@tornado.leadboat.com
>
> With or without the patch, reported performance figures are uninformative when
> thread start time is substantial relative to benchmark duration. A mere time
> accounting change will not help much; improving this requires tighter
> synchronization around the start of actual query activity across threads. I
> didn't read anything in your response as disagreement with that conclusion.

In my answer to the message you mention.

http://www.postgresql.org/message-id/alpine.DEB.2.02.1310011422130.324@sto

I explained why I had to re-take gettimeofday under --rate because the
start_time value cannot be relied on. The code I suggested simplifies the
logic by taking the time only once, instead of ignoring the first one
because it does not make sense. It seems to me that the logical answer to
this argument could have been "ok". But it seems that you do not percieve
my logic.

--
Fabien.