Re: pgstattuple: fix free space calculation

From: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
To: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgstattuple: fix free space calculation
Date: 2024-08-29 14:53:04
Message-ID: 0b29be81-c077-4280-8a3f-d0a70063d16a@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/23/24 12:51, Frédéric Yhuel wrote:
>
>
> On 8/23/24 12:02, Rafia Sabih wrote:
>> 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.
>
> We won't be able to add, but we will be able to update a tuple in this
> page.

Sorry, that's not true.

So in this marginal case we have free space that's unusable in practice.
No INSERT or UPDATE (HOT or not) is possible inside the page.

I don't know what pgstattuple should do in this case.

However, we should never encounter this case in practice (maybe on some
exotic architectures with strange alignment behavior?). As I said, I
can't fit more than 226 tuples per page on my machine, while
MaxHeapTuplesPerPage is 291. Am I missing something?

Besides, pgstattuple isn't mission critical, is it?

So I think we should just use PageGetExactFreeSpace().

Here is a v3 patch. It's the same as v2, I only removed the last
paragraph in the commit message.

Thank you Rafia and Andreas for your review and test.

Best regards,
Frédéric

Attachment Content-Type Size
v3-0001-pgstattuple-use-PageGetExactFreeSpace.patch text/x-patch 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Benoit Lobréau 2024-08-29 15:02:59 Re: Parallel workers stats in pg_stat_database
Previous Message Nathan Bossart 2024-08-29 14:49:44 Re: Partitioned tables and [un]loggedness