Re: non-HOT update not looking at FSM for large tuple update

John Naylor <john.naylor@enterprisedb.com>

From: John Naylor <john.naylor@enterprisedb.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: Floris Van Nee <florisvannee@optiver.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-03-17T20:51:48Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Accept slightly-filled pages for tuples larger than fillfactor.