RE: BITMAP Versus B-TREE

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <jkstill@xxxxxxxxx>, <yoursraju007@xxxxxxxxx>
  • Date: Tue, 26 Jun 2007 18:53:43 -0400

Piling on Jared's hyperbole, if the skew is extreme you may do very well by
designating NULL for the predominant value.

 

Especially when a "FLAG" exists for the purpose of sheparding something
through processing steps, being an indexible value for everything but "I'm
done, all y'all don't need to worry about me any more" can be put to
extremely efficient use IF it fits your situation.

 

Regards,

 

mwf

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jared Still
Sent: Tuesday, June 26, 2007 3:28 PM
To: yoursraju007@xxxxxxxxx
Cc: oracle-l
Subject: Re: BITMAP Versus B-TREE

 

On 6/25/07, Raj Mareddi <yoursraju007@xxxxxxxxx> wrote:

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...

<snip>
You may want to consider how this index is used, or even if 
it is ever used at all.  The CBO may be ignoring it entirely,
or possibly even using it when it is not a good idea.

What is the skew of these 2 values?

To engage in a bit of hyperbole: If the skew is 99% NO, and there 
are never any quries with YES as a predicate, the index is just a 
drain on resources.<snip>
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

Other related posts: