Re: WIP: BRIN multi-range indexes

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Mark Dilger <hornschnorter(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WIP: BRIN multi-range indexes
Date: 2018-02-05 18:57:06
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 01/23/2018 10:07 PM, Tomas Vondra wrote:
> On 01/23/2018 09:05 PM, Alvaro Herrera wrote:
>> This stuff sounds pretty nice. However, have a look at this report:
>> it seems to me that the new code is not tested at all. Shouldn't you
>> add a few more tests?
> I have a hard time reading the report, but you're right I haven't added
> any tests for the new opclasses (bloom and minmax_multi). I agree that's
> something that needs to be addressed.
>> I think 0004 should apply to unpatched master (except for the parts
>> that concern files not in master); sounds like a good candidate for
>> first apply. Then 0001, which seems mostly just refactoring. 0002 and
>> 0003 are the really interesting ones (minus the code removed by
>> 0004).
> That sounds like a reasonable plan. I'll reorder the patch series along
> those lines in the next few days.

And here we go. Attached is a reworked patch series that moves the IS
NULL tweak to the beginning of the series, and also adds proper
regression tests both for the bloom and multi-minmax opclasses. I've
simply copied the brin.sql tests and tweaked it for the new opclasses.

I've also added a bunch of missing multi-minmax opclasses. At this point
all data types that have minmax opclass should also have multi-minmax
one, except for these types:

* bytea
* char
* name
* text
* bpchar
* bit
* varbit

The reason is that I'm not quite sure how to define the 'distance'
function, which is needed when picking ranges to merge when
building/updating the index.

BTW while working on the regression tests, I've noticed that brin.sql
fails to test a couple of minmax opclasses (e.g. abstime/reltime). Is
that intentional or is that something we should fix eventually?


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
0001-Pass-all-keys-to-BRIN-consistent-function-at-once.patch text/x-patch 29.3 KB
0002-Move-IS-NOT-NULL-checks-to-bringetbitmap.patch text/x-patch 10.3 KB
0003-BRIN-bloom-indexes.patch text/x-patch 89.8 KB
0004-BRIN-multi-range-minmax-indexes.patch text/x-patch 146.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2018-02-05 19:46:33 Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Previous Message Peter Geoghegan 2018-02-05 18:03:41 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)