RE: bitmap conversion to rowids operation with btree indexes?

I will try to get it because the DBA is currenlty out of the office. We didn't prepare any trace files after he has changed the parameter because the response time was as expected (excellent).=20 But I have the run-time plan prepared by RBO for the same statement where the response time was 0.02s. I suspect that the plan=20 prepared by CBO will be quite similar.

I will also try to get 10053 trace to study it.=20 It smells me like a bug in CBO.

Kind regards, Joze

Rows Row Source Operation
---------- ---------------------------------------------------

        75  SORT ORDER BY=20
        75   UNION-ALL =20
        72    NESTED LOOPS =20
        72     NESTED LOOPS =20
        72      NESTED LOOPS =20
        72       NESTED LOOPS =20
        75        TABLE ACCESS BY INDEX ROWID PK  (object id 103596)
       229         INDEX RANGE SCAN PK_3  (object id 103815)
        72        TABLE ACCESS BY INDEX ROWID POLICE  (object id 104075)
        75         INDEX UNIQUE SCAN POLICE_1  (object id 104091)
        72       TABLE ACCESS BY INDEX ROWID FI_OSEBE  (object id =
103479)
        72        INDEX UNIQUE SCAN FI_OSEBE_1  (object id 103494)
        72      TABLE ACCESS BY INDEX ROWID PLAC_MESTA  (object id =
103912)
        72       INDEX UNIQUE SCAN PLAC_MESTA_1  (object id 103916)
        72     TABLE ACCESS BY INDEX ROWID DOK_PLACILA  (object id =
103466)
        72      INDEX UNIQUE SCAN DOK_PLACILA_1  (object id 103467)
         3    NESTED LOOPS =20
         3     NESTED LOOPS =20
         3      NESTED LOOPS =20
         3       NESTED LOOPS =20
        75        TABLE ACCESS BY INDEX ROWID PK  (object id 103596)
       229         INDEX RANGE SCAN PK_3  (object id 103815)
         3        TABLE ACCESS BY INDEX ROWID POLICE  (object id 104075)
        75         INDEX UNIQUE SCAN POLICE_1  (object id 104091)
         3       TABLE ACCESS BY INDEX ROWID PR_OSEBE  (object id =
104162)
         3        INDEX UNIQUE SCAN PR_OSEBE_1  (object id 104165)
         3      TABLE ACCESS BY INDEX ROWID PLAC_MESTA  (object id =
103912)
         3       INDEX UNIQUE SCAN PLAC_MESTA_1  (object id 103916)
         3     TABLE ACCESS BY INDEX ROWID DOK_PLACILA  (object id =
103466)
         3      INDEX UNIQUE SCAN DOK_PLACILA_1  (object id 103467)

-----Original Message-----

From: rshamsud_at_jcpenney.com [mailto:rshamsud_at_jcpenney.com] Sent: Wednesday, January 12, 2005 3:08 PM To: Joze Senegacnik; oracle-l_at_freelists.org Subject: RE: bitmap conversion to rowids operation with btree indexes?

I guess, AND_EQUAL / Logical OR is optimized to use bitmaps for obvious reasons, rather than ANDing or UNIONing the rowids. I can see that generating bitmap from rowids and degenerating rowids from bitmaps to be a costly operation, if the row source is smaller. But I always thought, if the # of rows from each index row source is high (98M & 2M in this case) and if the end result set is comparatively very small (just 226 rows here), then this specific access plan would be excellent.. Sort of using bitmap indices except the cardinality is much higher. Your experience just breaks that assumption!

Can you post the tuned explain plan also ? I am just wondering whether the reason for performance improvement is due to complete change in access plan or Is that by avoiding the rowid->bitmap->rowid conversion ?..

Thanks
Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA

--

http://www.freelists.org/webpage/oracle-l Received on Wed Jan 12 2005 - 08:35:12 CST