Re: Fix around conn_duration in pgbench

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Fix around conn_duration in pgbench
Дата
Msg-id 20210831.153918.1718001520194074466.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Fix around conn_duration in pgbench  (Yugo NAGATA <nagata@sraoss.co.jp>)
Ответы Re: Fix around conn_duration in pgbench  (Yugo NAGATA <nagata@sraoss.co.jp>)
Список pgsql-hackers
>> >> > 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".

I would think we should leave as it is for pg13 and before to not surprise users.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



В списке pgsql-hackers по дате отправления:

Предыдущее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: Pg stuck at 100% cpu, for multiple days
Следующее
От: "Pengchengliu"
Дата:
Сообщение: RE: suboverflowed subtransactions concurrency performance optimize