| From: | Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Change wait_time column of pg_stat_lock to double precision |
| Date: | 2026-06-20 06:44:52 |
| Message-ID: | CAHza6qd9tNhDWiOCqHOn76a5YsKQmFY5NVSaC6dkpi8nbkjF-A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-06-20 07:00:01 | Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain |
| Previous Message | Xuneng Zhou | 2026-06-20 06:41:35 | Re: Fix race in ReplicationSlotRelease for ephemeral slots |