| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | li(dot)evan(dot)chao(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Adjust pg_stat_get_lock() prorows to match lock types |
| Date: | 2026-06-08 05:45:10 |
| Message-ID: | aiZW5peZFBdQYq6o@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 08, 2026 at 02:20:00PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 4 May 2026 10:23:47 +0800, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote in
>> I read the code of pg_stat_lock() and played a bit with it. I happened =
>> to notice one thing: the function always returns 12 rows, but the =
>> planner estimates 10 rows:
>
> I'm not convinced this needs to be adjusted.
Neither am I. An estimate does not have to match the exact reality,
especially when it comes to these system functions. Just one example
from pg_proc.dat: pg_stat_get_io() has a prorows of 30, returns 95
rows.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-06-08 05:45:40 | Re: bugfix - fix broken output in expanded aligned format, when data are too short |
| Previous Message | Fujii Masao | 2026-06-08 05:34:43 | Re: Use correct type for catalog_xmin |