Re: Tid scan improvements - Mailing list pgsql-hackers

From Edmund Horner
Subject Re: Tid scan improvements
Date
Msg-id CAMyN-kDNwXnPmf9i_PxdQ2BmLfqy=JNQM_i9Ycj9tiba8z3yrQ@mail.gmail.com
Whole thread Raw
In response to Re: Tid scan improvements  (Edmund Horner <ejrh00@gmail.com>)
Responses Re: Tid scan improvements  (Thomas Munro <thomas.munro@gmail.com>)
Re: Tid scan improvements  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Mon, 22 Jul 2019 at 19:44, Edmund Horner <ejrh00@gmail.com> wrote:
> On Mon, 22 Jul 2019 at 19:25, David Rowley <david.rowley@2ndquadrant.com>
> > On Sat, 20 Jul 2019 at 06:21, Andres Freund <andres@anarazel.de> wrote:
> > > Yea, I was thinking of something like 2.  We already have a few extra
> > > types of scan nodes (bitmap heap and sample scan), it'd not be bad to
> > > add another. And as you say, they can just share most of the guts: For
> > > heap I'd just implement pagemode, and perhaps split heapgettup_pagemode
> > > into two parts (one to do the page processing, the other to determine
> > > the relevant page).
> > >
> > > You say that we'd need new fields in HeapScanDescData - not so sure
> > > about that, it seems feasible to just provide the boundaries in the
> > > call? But I think it'd also just be fine to have the additional fields.
> >
> > Thanks for explaining.
> >
> > I've set the CF entry for the patch back to waiting on author.
> >
> > I think if we get this part the way Andres would like it, then we're
> > pretty close.

> [...]

> I'll have to spend a bit of time looking at heapgettup_pagemode to
> figure how to split it as Andres suggests.

Hi everyone,

Sadly it is the end of the CF and I have not had much time to work on
this.  I'll probably get some time in the next month to look at the
heapam changes.

Should we move to CF?  We have been in the CF cycle for almost a year now...

Edmund



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Multivariate MCV list vs. statistics target
Next
From: Thomas Munro
Date:
Subject: Re: Rearranging ALTER TABLE to avoid multi-operations bugs