RE: non-HOT update not looking at FSM for large tuple update
Floris Van Nee <florisvannee@optiver.com>
From: Floris Van Nee <florisvannee@Optiver.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: John Naylor <john.naylor@enterprisedb.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-03-09T13:40:29Z
Lists: pgsql-hackers
Attachments
- v3-Allow-inserting-tuples-into-almost-empty-pages.patch (application/octet-stream) patch v3
Hi, > > This patch fails to consider that len may be bigger than MaxHeapTupleSize * > 0.98, which in this case triggers a reproducable > PANIC: Good catch! I've adapted the patch with your suggested fix. > > One different question I have, though, is why we can't "just" teach vacuum > to clean up trailing unused line pointers. As in, can't we trim the line pointer > array when vacuum detects that the trailing line pointers on the page are all > unused? > > The only documentation that I could find that this doesn't happen is in the > comment on PageIndexTupleDelete and PageRepairFragmentation, both not > very descriptive on why we can't shrink the page->pd_linp array. One is > "Unlike heap pages, we compact out the line pointer for the removed tuple." > (Jan. 2002), and the other is "It doesn't remove unused line pointers! Please > don't change this." (Oct. 2000), but I can't seem to find the documentation / > conversations on the implications that such shrinking would have. > This is an interesting alternative indeed. I also can't find any documentation/conversation about this and the message is rather cryptic. Hopefully someone on the list still remembers the reasoning behind this rather cryptic comment in PageRepairFragmentation. -Floris
Commits
-
Accept slightly-filled pages for tuples larger than fillfactor.
- 0ff8bbdee19a 14.0 landed