Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Tue, Jan 9, 2024 at 1:31 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Jan 9, 2024 at 10:56 AM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> > Andres had actually said that he didn't like pushing the update of
> > nonempty_pages into lazy_scan_[no]prune(). So, my v4 patch set
> > eliminates this.
>
> Mmph - but I was so looking forward to killing hastup!
>
> > Ultimately I can see arguments for and against. Is it better to avoid
> > having the same few lines of code in two places or avoid unneeded
> > communication between page-level functions and lazy_scan_heap()?
>
> To me, the conceptual complexity of an extra structure member is a
> bigger cost than duplicating TWO lines of code. If we were talking
> about 20 lines of code, I'd say rename it to something less dumb.

Yes, I agree. I thought about it more, and I prefer updating the FSM
and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I
had ordered the patch set with that first (before the patch to do
immediate reaping), but there is no reason for it to be so. Using
hastup can be done in a subsequent commit on top of the immediate
reaping patch. I will post a new version of the immediate reaping
patch which addresses your feedback. Then, separately, I will post a
revised version of the lazy_scan_heap() refactoring patches.

- Melanie