Re: Fix around conn_duration in pgbench - Mailing list pgsql-hackers

From Yugo NAGATA
Subject Re: Fix around conn_duration in pgbench
Date
Msg-id 20210831150326.5170a9fa068b22b740d62db3@sraoss.co.jp
Whole thread Raw
In response to Re: Fix around conn_duration in pgbench  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Responses Re: Fix around conn_duration in pgbench  (Tatsuo Ishii <ishii@sraoss.co.jp>)
List pgsql-hackers
On Tue, 31 Aug 2021 14:46:42 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:

> >> > My 0.02€: From a benchmarking perspective, ISTM that it makes sense to
> >> > include disconnection times, which are clearly linked to connections,
> >> > especially with -C. So I'd rather have the more meaningful figure even
> >> > at the price of a small change in an undocumented feature.
> >> 
> >> +1. The aim of -C is trying to measure connection overhead which
> >> naturally includes disconnection overhead.
> > 
> > I think it is better to measure disconnection delays when -C is specified in
> > pg 14. This seems not necessary when -C is not specified because pgbench just
> > reports "initial connection time".
> 
> Ok.
> 
> > However, what about pg13 or later? Do you think we should also change the
> > behavior of pg13 or later? If so, should we measure disconnection delay even
> > when -C is not specified in pg13?
> 
> You mean "pg13 or before"?

Sorry, you are right. I mean "pg13 or before".

> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp


-- 
Yugo NAGATA <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Returning to Postgres community work
Next
From: hubert depesz lubaczewski
Date:
Subject: Re: Pg stuck at 100% cpu, for multiple days