BRIN range operator class - Mailing list pgsql-hackers

From Emre Hasegeli
Subject BRIN range operator class
Date
Msg-id 20141019170517.GA6250@hasegeli.com
Whole thread Raw
In response to Re: BRIN indexes - TRAP: BadArgument  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BRIN range operator class
List pgsql-hackers
> Once again, many thanks for the review.  Here's a new version.  I have
> added operator classes for int8, text, and actually everything that btree
> supports except:
>     bool
>     record
>     oidvector
>     anyarray
>     tsvector
>     tsquery
>     jsonb
>     range
>
> since I'm not sure that it makes sense to have opclasses for any of
> these -- at least not regular minmax opclasses.  There are some
> interesting possibilities, for example for range types, whereby we store
> in the index tuple the union of all the range in the block range.

I thought we can do better than minmax for the inet data type,
and ended up with a generalized opclass supporting both inet and range
types.  Patch based on minmax-v20 attached.  It works well except
a few small problems.  I will improve the patch and add into
a commitfest after BRIN framework is committed.

To support more operators I needed to change amstrategies and
amsupport on the catalog.  It would be nice if amsupport can be set
to 0 like amstrategies.

Inet data types accept IP version 4 and version 6.  It is not possible
to represent union of addresses from different versions with a valid
inet type.  So, I made the union function return NULL in this case.
Then, I tried to store if returned value is NULL or not, in
column->values[] as boolean, but it failed on the pfree() inside
brin_dtuple_initilize().  It doesn't seem right to free the values
based on attr->attbyval.

I think the same opclass can be used for geometric types.  I can
rename it to inclusion_ops instead of range_ops.  The GiST opclasses
for the geometric types use bounding boxes.  It wouldn't be possible
to use a different data type in a generic oplass.  Maybe STORAGE
parameter can be used for that purpose.

> (I had an opclass for anyenum too, but on further thought I removed it
> because it is going to be pointless in nearly all cases.)

It can be useful in some circumstances.  We wouldn't lose anything
by supporting more types.  I think we should even add an operator
class for boolean.

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Autovacuum fails to keep visibility map up-to-date in mostly-insert-only-tables
Next
From: Andres Freund
Date:
Subject: Re: Hide 'Execution time' in EXPLAIN (COSTS OFF)