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
- v4-0001-Fix-bug-in-heap-space-management-that-was-overly-.patch (application/octet-stream) patch v4-0001
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
-
Accept slightly-filled pages for tuples larger than fillfactor.
- 0ff8bbdee19a 14.0 landed