Re: pgbench progress report improvements - split 3 v2 - A - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench progress report improvements - split 3 v2 - A
Date
Msg-id alpine.DEB.2.02.1310061814320.18141@sto
Whole thread Raw
In response to Re: pgbench progress report improvements - split 3 v2 - A  (Noah Misch <noah@leadboat.com>)
Responses Re: pgbench progress report improvements - split 3 v2 - A  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
>>> 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.



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pgbench progress report improvements - split 3 v2 - A
Next
From: Kevin Grittner
Date:
Subject: Re: SSI freezing bug