Re: [HACKERS] WIP: BRIN bloom indexes

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] WIP: BRIN bloom indexes
Дата
Msg-id CANP8+jKqmYwFMN_NYfj6Dn=rmZ=p9PF+ZY5Wi0vEAs=_BCV4HA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] WIP: BRIN bloom indexes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] WIP: BRIN bloom indexes  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On 27 October 2017 at 07:20, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 19, 2017 at 10:15 PM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> Let's see a query like this:
>>
>>     select * from bloom_test
>>      where id = '8db1d4a6-31a6-e9a2-4e2c-0e842e1f1772';
>>
>> The minmax index produces this plan
>>
>>    Heap Blocks: lossy=2061856
>>  Execution time: 22707.891 ms
>>
>> Now, the bloom index:
>>
>>    Heap Blocks: lossy=25984
>>  Execution time: 338.946 ms
>
> It's neat to see BRIN being extended like this.  Possibly we could
> consider making it a contrib module rather than including it in core,
> although I don't have strong feelings about it.

I see that SP-GIST includes two operator classes in core, one default.

Makes sense to do the same thing with BRIN and add this new op class
as a non-default option in core.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: [HACKERS] Typos in src/backend/optimizer/README
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Re: Is anything preventing us from allowing write toforeign tables from standby?