From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, David Geier <geidav(dot)pg(at)gmail(dot)com> |
Subject: | Re: Eliminate redundant tuple visibility check in vacuum |
Date: | 2023-09-21 20:07:27 |
Message-ID: | CA+TgmoYv_vde7ERALf=DFu_uij6xp2J817vv0g19QFM0uOsOFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 21, 2023 at 3:53 PM Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-09-21 20:48:09 | Re: Index range search optimization |
Previous Message | Robert Haas | 2023-09-21 19:53:13 | Re: Eliminate redundant tuple visibility check in vacuum |