2013/9/12 Fabien COELHO <coe...@cri.ensmp.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. >