Re: heapam_index_build_range_scan's anyvisible

From: Ashwin Agrawal <aagrawal(at)pivotal(dot)io>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: heapam_index_build_range_scan's anyvisible
Date: 2019-07-30 20:54:59
Message-ID: CALfoeiugzuUbPXG0879Nhho7WzRdssirV3+owYow3hxMeB9-_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 16, 2019 at 10:22 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2019-07-11 17:27:46 -0700, Ashwin Agrawal wrote:
> > Please find attached the patch to remove IndexBuildCallback's dependency
> on
> > HeapTuple, as discussed. Changed to have the argument as ItemPointer
> > instead of HeapTuple. Other larger refactoring if feasible for
> > index_build_range_scan API itself can be performed as follow-up changes.
>
> > From f73b0061795f0c320f96ecfed0c0602ae318d73e Mon Sep 17 00:00:00 2001
> > From: Ashwin Agrawal <aagrawal(at)pivotal(dot)io>
> > Date: Thu, 11 Jul 2019 16:58:50 -0700
> > Subject: [PATCH v1] Remove IndexBuildCallback's dependency on HeapTuple.
> >
> > With IndexBuildCallback taking input as HeapTuple, all table AMs
> > irrespective of storing the tuples in HeapTuple form or not, are
> > forced to construct HeapTuple, to insert the tuple in Index. Since,
> > only thing required by the index callbacks is TID and not really the
> > full tuple, modify callback to only take ItemPointer.
>
> Looks good to me. Planning to apply this unless somebody wants to argue
> against it soon?
>

Andres, I didn't yet register this for next commitfest. If its going in
soon anyways will not do it otherwise let me know and I will add it to the
list.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-07-30 21:17:59 Re: idea: log_statement_sample_rate - bottom limit for sampling
Previous Message Bruce Momjian 2019-07-30 20:48:31 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)