Re: [PATCH] Change wait_time column of pg_stat_lock to double precision

Поиск
Список
Период
Сортировка
Искать
От
Tatsuya Kawata
Тема
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision
Дата
в 09:44:52
Msg-id
CAHza6qd9tNhDWiOCqHOn76a5YsKQmFY5NVSaC6dkpi8nbkjF-A@mail.gmail.com
Ответ на
Список
Дерево обсуждения
[PATCH] Change wait_time column of pg_stat_lock to double precision Tatsuya Kawata <kawatatatsuya0913@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Tatsuya Kawata <kawatatatsuya0913@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Tatsuya Kawata <kawatatatsuya0913@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Michael Paquier <michael@paquier.xyz>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Michael Paquier <michael@paquier.xyz>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: [PATCH] Change wait_time column of pg_stat_lock to double precision Tatsuya Kawata <kawatatatsuya0913@gmail.com>
Hi Bertrand-san, Horiguchi-san,

Thanks for confirming the original intent.

Before we conclude, I would like to share a couple of points that
make me wonder whether changing the type might still be worth
considering.

1. pg_stat_lock is new in v19, so the type can still be changed
   before release without any backwards-compatibility cost.  This
   makes now a relatively low-risk moment to revisit the choice.

2. Looking across the other stats views, the "sub-millisecond
   precision is not particularly useful" criterion does not seem to
   be the basis for picking a type in general.
   pg_stat_database.session_time, for example, can accumulate to
   large values for which sub-millisecond precision is also noise,
   yet it uses double precision.  From a user's point of view,
   the common pattern across the stats views seems to be
   "measured time columns are double precision", regardless of
   expected magnitude or required precision.

3. As a minor point, deadlock_timeout is a GUC and can be lowered,
   so under diagnostic configurations sub-millisecond precision
   in wait_time is not entirely hypothetical.

So my point is not that the original bigint choice was wrong, but
that pg_stat_lock currently differs from the other stats views in
this respect, and v19 may be a good moment to make it uniform.

If the consensus after considering these points is still that the
existing bigint type is preferable, I am happy to withdraw and send
a docs-only patch making the rationale explicit instead.

Regards,
Tatsuya Kawata

В списке pgsql-hackers по дате отправления
От: Xuneng Zhou
Дата:
От: Alexander Lakhin
Дата:
FAQ