pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedIndex usage in bitwise operation context
2+ messages / 2 participants
[nested] [flat]
* Index usage in bitwise operation context
@ 2007-09-13 12:34 W.Alphonse HAROUNY <wharouny@gmail.com>
0 siblings, 1 reply; 2+ messages in thread
From: W.Alphonse HAROUNY @ 2007-09-13 12:34 UTC (permalink / raw)
To: pgsql-sql
Hello,
My question is about index usage when bitwise operations are invoked.
Situation Context:
--------------------------
Lets suppose we have 2 tables TBL1 and TBL2 as the following:
TBL1 {
......... ;
integer categoryGroup; // categoryGroup is declared as an index on TABL1
......... ;
}
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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Index usage in bitwise operation context
@ 2007-09-13 22:55 Gregory Stark <stark@enterprisedb.com>
parent: W.Alphonse HAROUNY <wharouny@gmail.com>
0 siblings, 0 replies; 2+ messages in thread
From: Gregory Stark @ 2007-09-13 22:55 UTC (permalink / raw)
To: W.Alphonse HAROUNY <wharouny@gmail.com>; +Cc: pgsql-sql
"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 like
WHERE 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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2007-09-13 22:55 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-09-13 12:34 Index usage in bitwise operation context W.Alphonse HAROUNY <wharouny@gmail.com>
2007-09-13 22:55 ` Gregory Stark <stark@enterprisedb.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox