BRIN range operator class
От | Emre Hasegeli |
---|---|
Тема | BRIN range operator class |
Дата | |
Msg-id | 20141019170517.GA6250@hasegeli.com обсуждение исходный текст |
Ответ на | Re: BRIN indexes - TRAP: BadArgument (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BRIN range operator class
|
Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: