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 |
Message-ID: | 20210831.141848.882802475820344457.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
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 |