From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: BRIN bloom indexes |
Date: | 2017-10-27 07:34:10 |
Message-ID: | CANP8+jKqmYwFMN_NYfj6Dn=rmZ=p9PF+ZY5Wi0vEAs=_BCV4HA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27 October 2017 at 07:20, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 19, 2017 at 10:15 PM, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-10-27 07:44:36 | Re: Re: Is anything preventing us from allowing write to foreign tables from standby? |
Previous Message | Etsuro Fujita | 2017-10-27 07:34:08 | Typos in src/backend/optimizer/README |