Re: Fix around conn_duration in pgbench

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: coelho(at)cri(dot)ensmp(dot)fr
Cc: masao(dot)fujii(at)oss(dot)nttdata(dot)com, nagata(at)sraoss(dot)co(dot)jp, asifr(dot)rehman(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Fix around conn_duration in pgbench
Date: 2021-08-31 05:18:48
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>>> Ok. That makes sense. The output reports "including connections
>>> establishing" and "excluding connections establishing" regardless with
>>> -C, so we should measure delays in the same way.
>> On second thought, it's more reasonable and less confusing not to
>> measure the disconnection delays at all? Since whether the benchmark
>> result
>> should include the disconnection delays or not is not undocumented,
>> probably we cannot say strongly the current behavior (i.e., the
>> disconnection
>> delays are not measured) is a bug. Also since the result has not
>> included
>> the disconnection delays so far, the proposed change might slightly
>> change
>> the benchmark numbers reported, which might confuse the users.
>> ISTM that at least it's unwise to change long-stable branches for
>> this... Thought?
> 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.
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2021-08-31 05:20:31 Re: Added schema level support for publication.
Previous Message Yugo NAGATA 2021-08-31 05:15:10 Re: Fix around conn_duration in pgbench