| From: | Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | 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-15 13:12:08 |
| Message-ID: | CAHza6qe7wqENFxbnkeRCugZYQcfH5p9FrqGSpe-WjxHD7=iDnQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Horiguchi-san,
Thanks for the review!
> since wait_time is only accumulated for waits longer
> than deadlock_timeout, sub-millisecond precision was probably not
> considered particularly useful.
You are right that, given the deadlock_timeout floor (which is a
GUC, but defaults to one second), each individual wait is already
on the order of one second, so the sub-millisecond remainder is at
most about 0.1% of the value being recorded. The precision
argument is therefore weak on its own, and I do not want to insist
on it.
The primary motivation I had in mind is consistency across the
statistics views: pg_stat_lock is the only one whose timing column
is not double precision. Even if the bigint choice was deliberate,
the view ends up breaking the pattern.
If we decide to keep bigint, I think it would be worth documenting
the reason explicitly (e.g. that wait_time is only accumulated
for waits longer than deadlock_timeout, hence sub-millisecond
precision is not needed).
Thoughts?
Regards,
Tatsuya Kawata
| From | Date | Subject | |
|---|---|---|---|
| Next Message | torikoshia | 2026-06-15 13:26:32 | Re: RFC: Logging plan of the running query |
| Previous Message | Álvaro Rodríguez | 2026-06-15 13:01:57 | Re: Unexpected reindex when altering column types for partitioned tables |