Tom Lane wrote:
> Nor rtree (our rtree implementation can only do 2-D
>AFAIK).
>
I know that... But, I thought, if I knew the set of requirements for the
rtree strategies and support funcs., I could come up with a set of
functions that would simulate the 2-D metrics, yet do what I need...
(ALL that I need really is to test if a & b = b - I just can't believe
there is no simple way to do that!).
>
>
>You might have better luck with GIST. In particular contrib/intarray
>would be worth looking at for inspiration.
>
Yeah... I looked at it... It scared the hell out of me - seemed to be
too damn complicated :-)
I mean, I just can't affort spending months on this thing - I have a
huge project to work on, and this is just one , really small, part of it...
Perhaps, if I it was documented a little better, I would be able to make
some sense of it in a reasonable time, but just going through all that
code and trying to guess what it is used for, doesn't look like an
option to me (especially, provided that I am not familiar with postgres
sources it is using, so, it is really a lot more stuff for me to go
through) :-(
>(You could even use it
>directly if you cared to change your data representation, I think.)
>
You mean to use an array of 15 ints instead of a single bit-packed
representation?
Well... I said before - the table is HUGE (60 million of rows), and
these 15 attributes is not the only stuff in it... So, my immediate
concern about changing the representation is if I am going to be able to
afford so much more disk space...
And then, there are other issues... I wanted it to be a btree, to begin
with, because these are not the only 15 attributes I need to use in the
search criteria - so, I was hoping to use a multicolumn btree, with my
bitset just being one of many columns in it... and if I opt for a gist
(or even an rtree), that's not an option...
Ohh... tough luck - sounds like I am going to have to stick with a
"straight" btree index, plus a lot of postprocessing afterwards :-(
Dima