Thread

1. Adjust pg_stat_get_lock() prorows to match lock types

   Chao Li <li.evan.chao@gmail.com> — 2026-05-04T02:23:47Z

   Hi,
   
   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:
   
   ```
   evantest=# EXPLAIN ANALYZE SELECT * FROM pg_catalog.pg_stat_lock;
                                                         QUERY PLAN
   -----------------------------------------------------------------------------------------------------------------------
    Function Scan on pg_stat_get_lock l  (cost=0.00..0.10 rows=10 width=64) (actual time=0.067..0.071 rows=12.00 loops=1)
    Planning Time: 0.121 ms
    Execution Time: 0.126 ms
   (3 rows)
   ```
   
   Then I found that, in pg_proc.dat, the function's prorows is defined as 10. Since the function returns one row per lock type, and lock types are not something that change frequently, I think it is better to give the planner a more accurate row count. After changing prorows to 12, the plan looks like this:
   
   ```
   evantest=# EXPLAIN ANALYZE SELECT * FROM pg_catalog.pg_stat_lock;
                                                         QUERY PLAN
   -----------------------------------------------------------------------------------------------------------------------
    Function Scan on pg_stat_get_lock l  (cost=0.00..0.12 rows=12 width=64) (actual time=0.134..0.138 rows=12.00 loops=1)
    Planning:
      Buffers: shared hit=13
    Planning Time: 0.313 ms
    Execution Time: 0.228 ms
   (5 rows)
   ```
   
   While there, I also made two small tweaks to two function comments in pgstat_lock.c. If those are not considered worth changing, I am okay with removing them from the patch.
   
   Please see the attached patch for details.
   
   Best regards,
   --
   Chao Li (Evan)
   HighGo Software Co., Ltd.
   https://www.highgo.com/
   
   
   
   
   

2. Re: Adjust pg_stat_get_lock() prorows to match lock types

   Chao Li <li.evan.chao@gmail.com> — 2026-05-15T08:34:41Z

   
   > On May 4, 2026, at 10:23, Chao Li <li.evan.chao@gmail.com> wrote:
   > 
   > Hi,
   > 
   > 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:
   > 
   > ```
   > evantest=# EXPLAIN ANALYZE SELECT * FROM pg_catalog.pg_stat_lock;
   >                                                      QUERY PLAN
   > -----------------------------------------------------------------------------------------------------------------------
   > Function Scan on pg_stat_get_lock l  (cost=0.00..0.10 rows=10 width=64) (actual time=0.067..0.071 rows=12.00 loops=1)
   > Planning Time: 0.121 ms
   > Execution Time: 0.126 ms
   > (3 rows)
   > ```
   > 
   > Then I found that, in pg_proc.dat, the function's prorows is defined as 10. Since the function returns one row per lock type, and lock types are not something that change frequently, I think it is better to give the planner a more accurate row count. After changing prorows to 12, the plan looks like this:
   > 
   > ```
   > evantest=# EXPLAIN ANALYZE SELECT * FROM pg_catalog.pg_stat_lock;
   >                                                      QUERY PLAN
   > -----------------------------------------------------------------------------------------------------------------------
   > Function Scan on pg_stat_get_lock l  (cost=0.00..0.12 rows=12 width=64) (actual time=0.134..0.138 rows=12.00 loops=1)
   > Planning:
   >   Buffers: shared hit=13
   > Planning Time: 0.313 ms
   > Execution Time: 0.228 ms
   > (5 rows)
   > ```
   > 
   > While there, I also made two small tweaks to two function comments in pgstat_lock.c. If those are not considered worth changing, I am okay with removing them from the patch.
   > 
   > Please see the attached patch for details.
   > 
   > Best regards,
   > --
   > Chao Li (Evan)
   > HighGo Software Co., Ltd.
   > https://www.highgo.com/
   > 
   > 
   > 
   > 
   > <v1-0001-Adjust-pg_stat_get_lock-row-estimate-and-comments.patch>
   
   Rebased.
   
   Best regards,
   --
   Chao Li (Evan)
   HighGo Software Co., Ltd.
   https://www.highgo.com/