Re: non-HOT update not looking at FSM for large tuple update - Mailing list pgsql-hackers

From John Naylor
Subject Re: non-HOT update not looking at FSM for large tuple update
Date
Msg-id CAFBsxsG8WWq9oNFbQon3rBPWTYrQSwYNmzjbp8a92BCg6vO5iQ@mail.gmail.com
Whole thread Raw
Responses Re: non-HOT update not looking at FSM for large tuple update  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
On Fri, Mar 12, 2021 at 8:45 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
>
> If this case isn't added, the lower else branch will fail to find
> fitting pages for len > maxPaddedFsmRequest tuples; potentially
> extending the relation when there is actually still enough space
> available.

Okay, with that it looks better to go back to using Max().

Also in v4:

- With the separate constant you suggested, I split up the comment into two parts.
- I've added a regression test to insert.sql similar to your earlier test, but we cannot use vacuum, since in parallel tests there could still be tuples visible to other transactions. It's still possible to test almost-all-free by inserting a small tuple. 
- Draft commit message

--
John Naylor
EDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: VACUUM (DISABLE_PAGE_SKIPPING on)
Next
From: John Naylor
Date:
Subject: Re: WIP: BRIN multi-range indexes