Re: review: pgbench progress report improvements - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: review: pgbench progress report improvements
Date
Msg-id alpine.DEB.2.02.1309121604540.3884@localhost6.localdomain6
Whole thread Raw
In response to review: pgbench progress report improvements  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: review: pgbench progress report improvements
List pgsql-hackers
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

> 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Protocol forced to V2 in low-memory conditions?
Next
From: Stephen Frost
Date:
Subject: Re: Successor of MD5 authentication, let's use SCRAM