Re: WIP: BRIN multi-range indexes - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: WIP: BRIN multi-range indexes
Date
Msg-id CAPpHfdt=JgdcNn5ACv7ruNqXarkQG-96EFmyrH+Sn6ovK8_b6g@mail.gmail.com
Whole thread Raw
In response to Re: WIP: BRIN multi-range indexes  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
Hi, Tomas!

I took a look at this patchset.

On Tue, Jun 11, 2019 at 8:31 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> Attached is this patch series, rebased on top of current master and the
> opclass parameters patch [1]. I previously planned to keep those two
> efforts separate for a while, but I decided to give it a try and the
> breakage is fairly minor so I'll keep it this way - this patch has zero
> chance of getting committed with the opclass parameters patch anyway.

Great.  You can notice, Nikita updated opclass parameters patchset
providing uniform way of passing opclass parameters for all index
access methods.  We would appreciate if you share feedback on that.

> Aside from rebase and changes due to adopting opclass parameters, the
> patch is otherwise unchanged.
>
> 0001-0004 are just the opclass parameters patch series.
>
> 0005 adds opclass parameters to BRIN indexes (similarly to what the
> preceding parts to for GIN/GiST indexes).

I see this patch change validation and catalog entries for addvalue,
consistent and union procs.  However, I don't see additional argument
to be passed to those functions in this patch.  0009 adds argument to
addvalue.  Regarding consistent and union, new argument seems not be
added in any patch.  It's probably not so important if you're going to
rebase to current version of opclass parameters, because it provides
new way of passing opclass parameters to support functions.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Pulling up direct-correlated ANY_SUBLINK
Next
From: Antonin Houska
Date:
Subject: Re: Pulling up direct-correlated ANY_SUBLINK