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

Nitin Motiani <nitinmotiani@google.com>

From: Nitin Motiani <nitinmotiani@google.com>

To: Dilip Kumar <dilipbalaut@gmail.com>

Cc: pgsql-hackers@postgresql.org

Date: 2025-09-30T05:16:11Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

pgstattuple: Improve reports generated for indexes (hash, gist, btree)
- c207bf473ee9 13.23 landed
- ee2dbcad02c7 14.20 landed
- 49b5f0b53c63 15.15 landed
- c0f9fe877e23 16.11 landed
- 036decbba2af 17.7 landed
- fc295beb7b74 18.1 landed
- 684a745f5505 19 (unreleased) landed

Attachments

v2-0001-Fix-unexpected-zero-page-in-pgstattuple-for-hash-.patch (application/octet-stream) patch v2-0001

On Mon, Sep 29, 2025 at 9:03 AM Dilip Kumar <dilipbalaut@gmail.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