Date: Mon, 08 Jun 2026 14:20:00 +0900 (JST)
Message-Id: <20260608.142000.1993011436447649540.horikyota.ntt@gmail.com>
To: li.evan.chao@gmail.com
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Adjust pg_stat_get_lock() prorows to match lock types
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <75836FCA-2A8A-4DED-A13F-888595460A2D@gmail.com>
References: <75836FCA-2A8A-4DED-A13F-888595460A2D@gmail.com>
User-Agent: Mew version 6.8 on Emacs 29.4
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260608.142000.1993011436447649540.horikyota.ntt%40gmail.com>
Precedence: bulk

Hello.

At Mon, 4 May 2026 10:23:47 +0800, Chao Li <li.evan.chao@gmail.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.

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