Re: review: pgbench progress report improvements

2013/9/12 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>

>
> Hello Pavel,
>
> Thanks for your review.
>
>
> * patched with minor warning
>> * compilable cleanly
>> * zero impact on PostgreSQL server functionality
>> * it does what was in proposal
>> ** change 5sec progress as default (instead no progress)
>> ** finalise a rate limit support - fixes a latency calculation
>>
>
> Just a point about the motivation: the rationale for having a continuous
> progress report is that benchmarking is subject to possibly long warmup
> times, and thus a test may have to run for hours so as to be significant. I
> find running a command for hours without any hint about what is going on
> quite annoying.
>
>
> * code is clean
>> * documentation is included
>> * there is no voices against this patch and this patch increases a pgbench
>> usability/
>>
>> I have only one question. When I tested this patch with throttling I got a
>> very similar values of lag.
>>
>
> Yep. That is just good!
>
>
> What is sense, or what is semantic of this value?
>>
>
> The "lag" measures the stochastic processus health. Actually, it measures
> how far behind schedule the clients are when performing throttled
> transactions. If it was to increase, that would mean that something is
> amiss, possibly not enough client threads or other issues. If it is small,
> then all is well.
>
>
> It is not detailed documented.
>>
>
> It is documented in the section about the --rate option, see
> http://www.postgresql.org/**docs/devel/static/pgbench.html<http://www.postgresql.org/docs/devel/static/pgbench.html>

ok, I see it now.

So this patch is ready for commit

Regards

Pavel

>
>
> Should be printed this value in this form on every row? We can
>> print some warning when lag is higher than latency instead?
>>
>
> Hmmm... what is important is when the lag changes values.
>
> Generally one would indeed expect that to be smaller than the latency, but
> that is not really possible when transaction are very fast, say under "-S"
> with read-only queries that hit the memory cache.
>
> Also the problem with printing warnings is that it changes the output
> format, but it seems to me more useful to print the value, so that it can
> be processed automatically and simply.
>
> Also, from a remote client perspective, say a web application, the overall
> latency is the lag plus the transaction latency: you first wait to get
> through the database (lag), and then you can perform your transaction
> (latency).
>
>
> Or we can use this value, but it should be better documented, please.
>>
>
> Is the documentation pointed above enough?
>
> --
> Fabien.
>