Обсуждение: Proposal: fix range queries in btree_gin
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 :(
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.
With best regards,
Alexander Korotkov.
On 03/28/2014 04:30 PM, Alexander Korotkov wrote: > 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. This reminds me of my earlier experiment http://www.postgresql.org/message-id/51FBC99D.7040506@gmail.com even though my motivation was different: to make comparePartial() support function unnecessary. // Antonin Houska (Tony)