Re: [PATCH] Change wait_time column of pg_stat_lock to double precision
Tatsuya Kawata <kawatatatsuya0913@gmail.com>
From: Tatsuya Kawata <kawatatatsuya0913@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2026-06-20T06:44:52Z
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
Commits
-
Change stat_lock.wait_time to double precision
- ff6f6e0470ec 19 (unreleased) landed
- c776550e4662 master landed