Robert Haas <[email protected]> writes:
> On Sun, Jul 8, 2018 at 7:59 PM, Peter Geoghegan <[email protected]> wrote:
>> The whole "getting tired" thing is the root of the problem here, which
>> is why the pending v3 of my patch will remove that code completely
>> (_bt_findinsertloc() is streamlined).
> This seems like really interesting and important work. I wouldn't
> have foreseen that the "getting tired" code would have led to this
> kind of bloat (even if I had known about it at all). I wonder,
> though, whether it's possible that the reverse could happen in some
> other scenario. It seems to me that with the existing code, if you
> reinsert a value many copies of which have been deleted, you'll
> probably find partially-empty pages whose free space can be reused,
> but if there's one specific place where each tuple needs to go, you
> might end up having to split pages if the new TIDs are all larger or
> smaller than the old TIDs.
Yeah ... if memory serves, there were specific usage patterns where
that hack made things way better than they'd been before. (I do not
recall if the hack itself was mine, but I think I can be blamed for
the "getting tired" comment ...) I'd suggest git blaming your way
to the commit that put that in, and then checking the hackers archives
around that date for more info.
regards, tom lane
