Обсуждение: Index usage in bitwise operation context

Hello,

My question is about index usage when bitwise operations are invoked.

TBL2 {
  ......... ;
  integer categoryGroup; // categoryGroup is declared as an index on TABL2
  ......... ;
}

By conception, I suppose that:
- [categoryGroup] may hold a limited number of values, less than 32 values.
- [categoryGroup] is of type integer => it means 4 bytes => 32 bits
  => 32 places available to hold binary '0' or binary '1' values.
- [categoryGroup] is the result of an "OR bitwise operation" among a predefined set of variables [variableCategory].
   We suppose that [variableCategory] is of type integer (=>32 bits)
   and each binary value of [variableCategory] may only hold a single binary '1'.

Ex: variableCategory1 = 00000000000000000000000000000010
      variableCategory2 = 00000000000000000000000000100000
      variableCategory3 = 00000000000000000000000000001000

     If [categoryGroup] =  variableCategory1 | variableCategory2 | variableCategory3
    =>[categoryGroup] = 00000000000000000000000000101010

Question:
--------------
I have an SQL request similar to:

SELECT ..... FROM TBL1, TBL2 WHERE
 <inner join between TBL1 and TBL2 is True> AND
 TBL1.CATEGORY & TBL2.CATEGORY <> 0  //-- where & is the AND bitwise operator

Qst:
1/ IS the above SQL request will use the INDEX [categoryGroup] defined on TBL1 and TBL2 ?
2/ What should I do or How should I modify my SQL request in order
   to force the query engine to use an index ? (the already defined index or another useful index)

Thx a lot

"W.Alphonse HAROUNY" <wharouny@gmail.com> writes:

> Question:
> --------------
> I have an SQL request similar to:
>
> SELECT ..... FROM TBL1, TBL2 WHERE
>  <inner join between TBL1 and TBL2 is True> AND
>  TBL1.CATEGORY & TBL2.CATEGORY <> 0  //-- where & is the AND bitwise
> operator
>
> Qst:
> 1/ IS the above SQL request will use the INDEX [categoryGroup] defined on
> TBL1 and TBL2 ?

No, & isn't an indexable operator for any of the standard indexing methods.

You could create 32 partial indexes on some other key with clauses likeWHERE tbl1.category & 0100... = 0100...
But I don't think that would be useful for a join clause in any case.

Second idea, you could create an expression index on 
tbl1 (category & 0100... = 0100...,       category & 0010... = 0010...,       category & 0001... = 0001...,       ...)

Again I don't see that it's going to be used for a join condition.

Lastly, you could look for a GIST index method for varbit which would be
superior to both of the above tactics. I'm still not sure it would be able to
handle a join clause though, but maybe?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com