Re: GIN pending list clean up exposure to SQL

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: GIN pending list clean up exposure to SQL
Дата
Msg-id CAMkU=1xdv5n8w2-n4j_ysXy6eRd69XhWiGrdxQbqDjWEpBavww@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GIN pending list clean up exposure to SQL  (Jaime Casanova <jaime.casanova@2ndquadrant.com>)
Ответы Re: GIN pending list clean up exposure to SQL
Список 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 по дате отправления:

Предыдущее
От: Catalin Iacob
Дата:
Сообщение: Re: proposal: multiple psql option -c
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: Bug in numeric multiplication