Hello. At Mon, 4 May 2026 10:23:47 +0800, Chao Li <[email protected]> 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. The prorows value is only a rough estimate for the planner, not an exact row count. For example, pg_show_all_settings() has prorows = 1000, while it returns substantially fewer rows in my build. That suggests these values are intended to provide a reasonable estimate rather than an exact count. Given that, I don't think a difference between 10 and 12 rows is worth fixing. Keeping prorows synchronized with the exact number of lock types would only add maintenance overhead whenever a new lock type is introduced. If the current estimate is shown to cause a planning problem, I'd rather address that problem directly than try to keep prorows exactly synchronized with the number of lock types. This discussion also made me wonder whether the documentation could be a bit more explicit that prorows is intended as a planner estimate rather than an exact row count. > Estimated number of result rows (zero if not proretset) Regards. -- Kyotaro Horiguchi NTT Open Source Software Center
