Re: query not using bitmap index

Could be a problem with your hint because you should be able to force the optimiser to choose a bad execution path :) ..(your hint might require entry replaced with a table alias eg a)

Remember query performance is all about the mimimum amount of work required to return the required rows (the rowset).

If you have analysed the table (for table for all indexes for all indexed columns) you can review the distribution of values for type.

What you might find is the optimiser is ignoring the bitmap index if the number of blocks required to get "where type ='atype'" via a bitmap index scan is greater than the number of blocks required to perform a full table scan.
You can test this by forcing the use of the bitmap index with a hint

One nasty mistake people make with bitmap indexes is to assume that a query like
select name,address from customers where gender = 'M' will use a bitmap index.
Clearly, a normal population with have around 50% Males so the number of blocks reads required to return the rowset will be 3-4 times 50% blocks in table customer.

Bitmap indexes work better if used in groups eg customer(name,address,gender,suburb,state,country,postcode) Having a separate bitmap on each gender,suburb,state,country,postcode for a large customer table would make the following example query fly select *
from customer
where gender = 'M'
and suburb = 'Double Bay'
and state = 'NSW'
and country = 'AUSTRALIA'

BTW, the query
select count('x') from entry where type ='atype' is using the bitmap index as it faster to just read the bitmap index for a count then scan the whole table.

Have Fun

--
Posted via http://dbforums.com