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

On Sat, Mar 27, 2021 at 3:00 AM Noah Misch <noah(at)leadboat(dot)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.

> 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.

> Comments and the maxPaddedFsmRequest variable name use term "fsm" for
things
> not specific to the FSM. For example, the patch's test case doesn't use
the
> FSM. (That is fine. Ordinarily, RelationGetTargetBlock() furnishes its
> block. Under CLOBBER_CACHE_ALWAYS, the "try the last page" logic does
so. An
> FSM-using test would contain a VACUUM.) I plan to commit the attached
> version; compared to v5, it updates comments and renames this variable.

Looks good to me, thanks!

--
John Naylor
EDB: http://www.enterprisedb.com