From: | Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> |
---|---|
To: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgstattuple: fix free space calculation |
Date: | 2024-08-23 10:02:37 |
Message-ID: | CA+FpmFdjnEroLhH+JWbLCFzOpY_itf_TDA7csdfmEThH36pTQg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 23 Aug 2024 at 11:01, Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
wrote:
>
>
> On 8/22/24 21:56, Rafia Sabih wrote:
> > I agree with the approach here.
> > A minor comment here is to change the comments in code referring to the
> > PageGetHeapFreeSpace.
>
> Thank you Rafia. Here is a v2 patch.
>
> I've also added this to the commit message:
>
> Also, PageGetHeapFreeSpace() will return zero if there are already
> MaxHeapTuplesPerPage line pointers in the page and none are free. We
> don't want that either, because here we want to keep track of the free
> space after a page pruning operation even in the (very unlikely) case
> that there are MaxHeapTuplesPerPage line pointers in the page.
On the other hand, this got me thinking about the purpose of this space
information.
If we want to understand that there's still some space for the tuples in a
page, then using PageGetExactFreeSpace is not doing justice in case of heap
page, because we will not be able to add any more tuples there if there are
already MaxHeapTuplesPerPage tuples there.
--
Regards,
Rafia Sabih
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-08-23 10:13:22 | Re: Fix memory counter update in reorderbuffer |
Previous Message | Michael Harris | 2024-08-23 10:01:33 | Re: ANALYZE ONLY |