Re: pgstattuple "unexpected zero page" for gist and hash indexes

From: Nitin Motiani <nitinmotiani(at)google(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgstattuple "unexpected zero page" for gist and hash indexes
Date: 2025-09-30 05:16:11
Message-ID: CAH5HC94-+FTb1nGpfgSWOfq-bRfZ=1b=NbRuDdcRjForiw2LCQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 29, 2025 at 9:03 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> I observed that pgstat_btree_page() incorporates the count of new
> pages into its free space calculation[1]. Does it make sense to do the
> same for hash and gist as well as we are leaning towards making these
> consistent.
>
> [1]
> if (PageIsNew(page))
> {
> /* fully empty page */
> stat->free_space += BLCKSZ;
> }
>

Thanks for the feedback. Yes, it makes sense to do the same free space
calculation for the other index types unless there is some special
handling in btree implementation of the free space. From the
pgstattuple code, I don't see any special handling so I have made the
change suggested by you. I'm attaching patch v2 with that change.

Thanks

Attachment Content-Type Size
v2-0001-Fix-unexpected-zero-page-in-pgstattuple-for-hash-.patch application/octet-stream 2.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alena Vinter 2025-09-30 05:22:08 Re: Resetting recovery target parameters in pg_createsubscriber
Previous Message vignesh C 2025-09-30 04:57:48 Re: Skipping schema changes in publication