Well, These indexes do exist already. For example, there is a column called FLAG with values of 'YES' or 'NO' and there are 6 Millions of rows in the index... but distinct values are only two ('YES' and 'NO')... Im just thinking to convert this to Bitmap... did couple of ones and seen better performance... but just thining about loading on these tables... Thanks! On 6/25/07, Shamsudeen, Riyaj <RS2273@xxxxxxx> wrote:
Raj If there is high DML activity on the table, then careful consideration should be given while choosing bitmap index. By design, bitmap indices are not suitable for tables with high DML activity. I have created bitmap indices on columns with very few distinct values (10-) and also with high distinct values(Millions+), both improving performance. But, you said there is just one distinct value for a column? Why do you want to index that column? Michael, >>I find a little "buggier". What do you mean "buggier"? Do you have specific test case that proves that there are issues with bitmap index? And What version? What administration overhead are you referring to ? Thanks Riyaj Shamsudeen -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Michael McMullen Sent: Monday, June 25, 2007 8:16 AM To: 'oracle-l' Subject: RE: BITMAP Versus B-TREE Do you mean the column has only one value, including nulls? I wouldn't put an index on that. Yes, bitmaps are great for queries but a pain for loading. They can also really favour certain access paths and I find a little "buggier". They can also grow like crazy. I would say, if you heavily use bitmaps, it increases your administration. Like all things oracle, it's the details that kill you. -- //www.freelists.org/webpage/oracle-l -- //www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l