thanks for the support

followup - I rebuilt the index as a bitmap, and also corrected the bug,
now i access it thru its correct type. I only caught ther bug as I was
already rebuilding the index as a bitmap...

the access is really fast now, even though the CF is of course the
same. this tells me Oracle understands that since it has almost as many
distinct keys as a PK it can ignore the high CF

this table is updated in batches, in the OLTP is only selected, thus a
bitmap idnex is feasible.

now I have to rebuilt the index as a b-tree and check the difference. I
wil post the results in case anyone is still interested




I don't think I will rebuilt the table as along as I get results as of
now. At least I have learned a lot about indexes, CF and the all the
other good stuff. thanks again everone