Re: pgstattuple: fix free space calculation

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

In response to

Responses

Browse pgsql-hackers by date

  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