Re: GIN pending list clean up exposure to SQL - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: GIN pending list clean up exposure to SQL
Date
Msg-id CAMkU=1xdv5n8w2-n4j_ysXy6eRd69XhWiGrdxQbqDjWEpBavww@mail.gmail.com
Whole thread Raw
In response to Re: GIN pending list clean up exposure to SQL  (Jaime Casanova <jaime.casanova@2ndquadrant.com>)
Responses Re: GIN pending list clean up exposure to SQL  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Thu, Nov 19, 2015 at 8:37 AM, Jaime Casanova
<jaime.casanova@2ndquadrant.com> wrote:
> On 12 August 2015 at 20:19, Jeff Janes <jeff.janes@gmail.com> wrote:
>>
>> But where does this belong?  Core?  Its own separate extension?
>>
>
> I will say core. Gin indexes are in core and i don't see why this
> function shouldn't.
> FWIW, brin indexes has a similar function brin_summarize_new_values() in core


I was holding off on doing more on this until after the bug
http://www.postgresql.org/message-id/CAMkU=1xALfLhUUohFP5v33RzedLVb5aknNUjcEuM9KNBKrB6-Q@mail.gmail.com
was resolved, as I think it might change the way things work enough to
make a difference, at least to the documentation if not the
functioning.

I will look at brin_summarize_new_values for guidance.  But now we
have one vote for core and one for 'gevel' extension, so I'm not sure
where to go.  The nice thing about core is that is always there (in
the future) and maintained by a group of people, and as you point out
there is precedence with the BRIN index.  But the nice thing with an
extension is that it easier to adapt for existing installations, so
you don't have to wait for 9.6 to get access to it.

I'll prepare a patch for core for the January commitfest, and see if
it flies.  If not, there is always the extension to fall back to.

Cheers,

Jeff



pgsql-hackers by date:

Previous
From: Catalin Iacob
Date:
Subject: Re: proposal: multiple psql option -c
Next
From: Dean Rasheed
Date:
Subject: Re: Bug in numeric multiplication