On Thu, Mar 18, 2021 at 5:30 PM Matthias van de Meent < boekewurm+postg...@gmail.com> wrote: > > > + * The minimum space on a page for it to be considered "empty" regardless > > + * of fillfactor. We base this on MaxHeapTupleSize, minus a small amount > > + * of slack. We allow slack equal to 1/8 the maximum space that could be > > + * taken by line pointers, which is somewhat arbitrary. > > > + * We want to allow inserting a large tuple into an empty page even if > > + * that would violate the fillfactor. Otherwise, we would unnecessarily > > + * extend the relation. Instead, ask the FSM for maxPaddedFsmRequest > > + * bytes. This will allow it to return a page that is not quite empty > > + * because of unused line pointers > > How about > > + * Because pages that have no items left can still have space allocated > + * to item pointers, we consider pages "empty" for FSM requests when they > + * have at most 1/8 of their MaxHeapTuplesPerPage item pointers' space > + * allocated. This is a somewhat arbitrary number, but should prevent > + * most unnecessary relation extensions due to not finding "empty" pages > + * while inserting combinations of large tuples with low fillfactors. > > + * When the free space to be requested from the FSM is greater than > + * maxPaddedFsmRequest, this is considered equivalent to requesting > + * insertion on an "empty" page, so instead of failing to find a page > + * with more empty space than an "empty" page and extend the relation, > + * we try to find a page which is considered "emtpy". > > This is slightly more verbose, but I think this clarifies the > reasoning why we need this a bit better. Feel free to reject or adapt > as needed.
I like this in general, but still has some rough edges. I've made another attempt in v5 incorporating your suggestions. Let me know what you think. -- John Naylor EDB: http://www.enterprisedb.com
v5-0001-Fix-bug-in-heap-space-management-that-was-overly-.patch
Description: Binary data
