Re: pgstattuple: fix free space calculation
| От | Rafia Sabih |
|---|---|
| Тема | Re: pgstattuple: fix free space calculation |
| Дата | |
| Msg-id | CA+FpmFdjnEroLhH+JWbLCFzOpY_itf_TDA7csdfmEThH36pTQg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pgstattuple: fix free space calculation (Rafia Sabih <rafia.pghackers@gmail.com>) |
| Ответы |
Re: pgstattuple: fix free space calculation
Re: pgstattuple: fix free space calculation |
| Список | pgsql-hackers |
On Fri, 23 Aug 2024 at 11:01, Frédéric Yhuel <frederic.yhuel@dalibo.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
Rafia Sabih
В списке pgsql-hackers по дате отправления: