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 |
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 |