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

On Sat, Mar 27, 2021 at 11:26:47AM -0400, John Naylor wrote:
> On Sat, Mar 27, 2021 at 3:00 AM Noah Misch <noah@leadboat.com> wrote:
> > Does anyone have a strong opinion on whether to back-patch?  I am weakly
> > inclined not to back-patch, because today's behavior might happen to perform
> > better when large_upd_rate-small_ins_rate<0.
> 
> It's not a clear case. The present behavior is clearly a bug, but only
> manifests in rare situations. The risk of the fix affecting other situations
> is not zero, as you mention, but (thinking briefly about this and I could be
> wrong) the consequences don't seem as big as the reported case of growing
> table size.

I agree sites that are hurting now will see a net benefit.  I can call it a
bug that we treat just-extended pages differently from existing
zero-line-pointer pages (e.g. pages left by RelationAddExtraBlocks()).
Changing how we treat pages having 100 bytes of data feels different to me.
It's more like a policy decision, not a clear bug fix.

I'm open to back-patching, but I plan to do so only if a few people report
being firmly in favor.

> > Besides the usual choices of
> > back-patching or not back-patching, we could back-patch with a stricter
> > threshold.  Suppose we accepted pages for larger-than-fillfactor tuples when
> > the pages have at least
> > BLCKSZ-SizeOfPageHeaderData-sizeof(ItemIdData)-MAXALIGN(MAXALIGN(SizeofHeapTupleHeader)+1)+1
> > bytes of free space.  That wouldn't reuse a page containing a one-column
> > tuple, but it would reuse a page having up to eight line pointers.
> 
> I'm not sure how much that would help in the reported case that started this thread.

I'm not sure, either.  The thread email just before yours (27 Mar 2021
10:24:00 +0000) does suggest it would help less than the main proposal.