Re: BITMAP Versus B-TREE

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_at_att.com> 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_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] 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.
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l