Re: pgbench: option delaying queries till connections establishment?

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: andres(at)anarazel(dot)de, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench: option delaying queries till connections establishment?
Date: 2020-02-29 14:39:06
Message-ID: alpine.DEB.2.21.2002291531360.25187@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Kyotaro-san,

>> I think this also shows that "including/excluding connections
>> establishing" as well as some of the other stats reported pretty
>> bogus. In the 'before' case a substantial numer of the connections had
>> not yet been established until the end of the test run!
>
> I see it useful. In most cases we don't care connection time of
> pgbench. Especially in the mentioned case the result is just bogus. I
> think the reason for "including/excluding connection establishing" is
> not that people wants to see how long connection took to establish but
> that how long the substantial work took. If each client did run with
> continuously re-establishing new connections the connection time would
> be useful, but actually all the connections are established at once at
> the beginning.
>
> So FWIW I prefer that the barrier is applied by default

Yep.

> (that is, it can be disabled)

On reflection, I'm not sure I see a use case for not running the barrier
if it is available.

> and the progress time starts at the time all clients has been
> established.

Yep, the start time should be set after the connection barrier, and
possibly before a start barrier to ensure that no transaction has started
before the start time: although performance measures are expected to be
slightly false because of how they are measured (measuring takes time),
from a benchmarking perspective the displayed result should be <= the
actual performance.

Now, again, if long benchmarks are run, which for a db should more or less
always be the case, this should not matter much.

>> starting vacuum...end.
> + time to established 5000 connections: 1323ms

Yep, maybe showing the initial connection time separately.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-02-29 14:44:26 Re: SLRU statistics
Previous Message Fabien COELHO 2020-02-29 14:29:19 Re: pgbench: option delaying queries till connections establishment?