Re: Eliminate redundant tuple visibility check in vacuum - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Eliminate redundant tuple visibility check in vacuum
Date
Msg-id CA+TgmoYv_vde7ERALf=DFu_uij6xp2J817vv0g19QFM0uOsOFw@mail.gmail.com
Whole thread Raw
In response to Re: Eliminate redundant tuple visibility check in vacuum  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Sep 21, 2023 at 3:53 PM Robert Haas <robertmhaas@gmail.com> wrote:
> > >  static int   heap_prune_chain(Buffer buffer,
> > >                                                        OffsetNumber rootoffnum,
> > > +                                                      int8 *htsv,
> > >                                                        PruneState *prstate);
> >
> > Hm, do we really want to pass this explicitly to a bunch of functions? Seems
> > like it might be better to either pass the PruneResult around or to have a
> > pointer in PruneState?
>
> As far as I can see, 0002 adds it to one function (heap_page_pune) and
> 0003 adds it to one more (heap_prune_chain). That's not much of a
> bunch.

I didn't read this carefully enough. Actually, heap_prune_chain() is
the *only* function that gets int8 *htsv as an argument. I don't
understand how that's a bunch ... unless there are later patches not
shown here that you're worried abot. What happens in 0002 is a
function getting PruneResult * as an argument, not int8 *htsv.

Honestly I think 0002 and 0003 are ready to commit, if you're not too
opposed to them, or if we can find some relatively small changes that
would address your objections.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Eliminate redundant tuple visibility check in vacuum
Next
From: Peter Geoghegan
Date:
Subject: Re: Index range search optimization