Horton

Re: pgstattuple: fix free space calculation

Frédéric Yhuel <frederic.yhuel@dalibo.com>

View thread
From: Frédéric Yhuel <frederic.yhuel@dalibo.com>
To: Rafia Sabih <rafia.pghackers@gmail.com>, Andreas Karlsson <andreas@proxel.se>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-08-29T14:53:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Consistently use PageGetExactFreeSpace() in pgstattuple.

Attachments


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