Hackers,
after reading Heikki Linnakangas presentation about GIN from Nordic PGDay,
I figure out that btree_gin became much more attractive.
http://hlinnaka.iki.fi/presentations/NordicPGDay2014-GIN.pdf
But it have one weird behaviour: when you have range restriction like col
const1 AND col const2 it's handled as intersection of two separate
partial matches col const1 and col const2. So, it's awfully slow :(
The opclass can't handle it better because it only deals with col
const1 and col const2 separately. This two restrictions are
separately passed to gin_extract_query.
This problem is known, but now I can propose some solution.
We have range types, and restriction col @ range can be correctly
handled by gin_extract_query, because it will be passed there as single
restriction. This is workaround itself, but it's weird to force users
express queries like this.
We can add some logic to gin. If it sees:
1) Query contain both col const1 and col const2 restrictions.
2) There is a range type for this type and comparison operator.
3) opclass supports col @ range
then rewrite this two restrictions as col @ range(const1, const2)
--
With best regards,
Alexander Korotkov.
