BRIN range operator class
Emre Hasegeli <emre@hasegeli.com>
From: Emre Hasegeli <emre@hasegeli.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>,
Erik Rijkers <er@xs4all.nl>, Emanuel Calvo <3manuek@esdebian.org>,
Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
Nicolas Barbier <nicolas.barbier@gmail.com>,
Claudio Freire <klaussfreire@gmail.com>, Josh Berkus <josh@agliodbs.com>,
Andres Freund <andres@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-10-19T17:05:17Z
Lists: pgsql-hackers
Attachments
- brin-range-v01.patch (text/x-diff) patch v1
> 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.
Commits
-
Refactor per-page logic common to all redo routines to a new function.
- f8f4227976a2 9.5.0 cited
-
Reduce use of heavyweight locking inside hash AM.
- 76837c1507cb 9.3.0 cited
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited
-
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
- 9e2a87b62db8 7.1.1 cited