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.pdfBut 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.
