>
>
>
>SELECT * FROM table where (bitstring & 7) = 7;
>
>Will this not give you the correct answer and use the index on bitstring?
>
Yes, and know... (Yes, it will give th ecorrect answer, and NO it will
not use the index).
The thing is, that it will only use a (btree) index for one of the
'comparison' operators
(<=, <, =, >, >=), that compare the value in the table with the query
parameter - so,
bitstring = 7, or bitstring < 7 etc... will work, but
'do_something_to_bitstring = 7' will not (I mean, it will, but it won't
use the index).
So, the idea is to redefine those comparison operators for the index, so
that I could use one of them fopr my purpose - for example (as I
mentioned in the original message), I was trying to define a '<<='
("less or equals") operator as a <<= b iff a & b = a.
My problem is that (as far as I understand) the way I am doing it will
not work (my set of operators doesn't define a strict ordering, so that
not any pair of values is comparable) :-(
And what I am looking for is either a suggestion of how this strict
ordering can be defined, or a description of what exactly the btree
needs to work (I suspect, that completely strict ordering is not really
necesssary, and that I could get away with some kind of a partial order,
if I new exactly what the btree stuff is looking for)...
Dima
