Re: Reading all tuples in Index Access Method

From: Sushrut Shivaswamy <sushrut(dot)shivaswamy(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reading all tuples in Index Access Method
Date: 2024-08-28 16:57:58
Message-ID: CAH5mb9_SdVEse70Vm9bxnaeai-YeGjAK6APPJkgjR6Bm==OK+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks Matthias, table_index_build_scan sounds like what I"m looking for.

On Wed, Aug 28, 2024 at 9:29 PM Matthias van de Meent <
boekewurm+postgres(at)gmail(dot)com> wrote:

> On Wed, 28 Aug 2024 at 16:21, Sushrut Shivaswamy
> <sushrut(dot)shivaswamy(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > I'm trying to create an Index Access Method Roting.
> > Building the index requires iterating over all rows and calculating,
> > which is then used during index construction.
> >
> > The methods in the IndexAmRoutine seem to deal with insertion / index
> build one row at a time.
> > Is there any workaround you can suggest that would allow me to calculate
> the median of a column,
> > store it someplace and then use it during Inserts to the index?
>
> I'm not sure what to say. Index insertions through indam->aminsert
> happen as users insert new values into the table, so I don't see how a
> once-calculated median would remain correct across an index's
> lifespan: every time I insert a new value (or delete a tuple) the
> median will change. Furthermore, indexes will not know about deletions
> and updates until significantly after the deleting or updating
> transaction got committed, so transactionally consistent aggregates
> are likely impossible to keep consistent while staying inside the
> index AM API.
>
> However, if you only need this median (or other aggregate) at index
> build time, you should probably look at various indexes'
> indam->ambuild functions, as that function's purpose is to build a new
> index from an existing table's dataset, usually by scanning the table
> with table_index_build_scan.
>
> As for storing such data more permanently: Practically all included
> indexes currently have a metapage at block 0 of the main data fork,
> which contains metadata and bookkeeping info about the index's
> structure, and you're free to do the same for your index.
>
> I hope that helps?
>
> Kind regards,
>
> Matthias van de Meent
> Neon (https://neon.tech)
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-08-28 17:06:35 Re: allowing extensions to control planner behavior
Previous Message Andreas Karlsson 2024-08-28 16:43:49 Re: tiny step toward threading: reduce dependence on setlocale()