RE: bitmap conversion on a index that is not bitmapped ???
Thanks for your comments. You are correct that AIF_OUTBOUND_IX01 is more selective than AIF_OUTBOUND_IX03. From what I am seeing, degree is affecting the plan. If I delete stats, alter index parallel 10, analyze table estimate stats - the bitmap conversion plan is used. If I delete stats, alter index parallel 10 and renalyze, it goes back to the index range scan. At this point, I can accept it - although I am curious as to why it has happening. And can I use degree on other indexes where a index range scan is being done to help performance? So many questions, so little time. -Original Message-From: Khedr, Waleed [mailto:[EMAIL PROTECTED]Sent: Wednesday, October 15, 2003 6:39 PMTo: Multiple recipients of list ORACLE-LSubject: RE: bitmap conversion on a index that is not bitmapped ??? It seems that you have tow predicates in the where clause that can take advantage of two different indexes. Also you have "AND" condition that Oracle tries to take advantage of using "BITMAP AND" operation. Since you like the performance of the plan that uses the BITMAP conversion, I can say that index "'AIF.AIF_OUTBOUND_IX01" is more selective than "'AIF.AIF_OUTBOUND_IX03" And in the second plan that one that does not use the BITMAP, if you force it to use index IX01, it would be faster. Degree has nothing to do to the index performance except when doing Index FFS. Regards, Waleed -Original Message-From: Fedock, John (KAM.RHQ) [mailto:[EMAIL PROTECTED]Sent: Wednesday, October 15, 2003 12:50 PMTo: Multiple recipients of list ORACLE-LSubject: bitmap conversion on a index that is not bitmapped ??? Platform is 8.1.7.4, HP-UX 11.00 I have a complex view. After rebuilding all indexes this weekend, the view got much faster. I did a trace on it. Now, a few days later, the view is getting much slower. Yes, an analyze has run since then, doing an 'estimate statistics', but an estimate stats was done after the rebuilds as well. The difference in the explain is below - please note that bitmapped conversion info (in bold): Good plan: ..67 .FIRST ROW..66 ..VIEW OF 'GAPP_USER. (CARD=1 BYTES=13 )..65 ..SORT (AGGREGATE) (CARD=1 BYTES=121 )..64 NESTED LOOPS (COST=53 CARD=1 BYTES=121 )..61 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.AIF_OUTBOUND' (COST=51 CARD=1 BYTES=86 )..60 ..BITMAP CONVERSION (TO ROWIDS)..59 ...BITMAP AND..55 BITMAP CONVERSION (FROM ROWIDS)..54 .INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX03' (NON-UNIQUE) (COST=4 )..58 BITMAP CONVERSION (FROM ROWIDS)..57 .SORT (ORDER BY)..56 ..INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX01' (NON-UNIQUE) (COST=11 )..63 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.EDI_ROUTE' (COST=1 CARD=65 BYTES=2275 )..62 ..INDEX (UNIQUE SCAN) OF 'AIF.EDI_ROUTE_PK' (UNIQUE) (CARD=65 ) Bad plan: ..61 .FIRST ROW..60 ..VIEW OF 'GAPP_USER. (CARD=1 BYTES=13 )..59 ..SORT (AGGREGATE) (CARD=1 BYTES=121 )..58 NESTED LOOPS (COST=52 CARD=1 BYTES=121 )..55 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.AIF_OUTBOUND' (COST=51 CARD=1 BYTES=86 )..54 ..INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX03' (NON-UNIQUE) (COST=3 CARD=1 )..57 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.EDI_ROUTE' (COST=1 CARD=65 BYTES=2275 )..56 .INDEX (UNIQUE SCAN) OF 'AIF.EDI_ROUTE_PK' (UNIQUE) (CARD=65 ) The interesting thing is, the table in question does not have any bit mapped indexes on it. Some notes on MetaLink show other people questioning the same issue, but no concrete info is given. Any ideas out there? TIA. John John Fedock "K" Line America, Inc. www.kline.com * [EMAIL PROTECTED]
RE: bitmap conversion on a index that is not bitmapped ???
It seems that you have tow predicates in the where clause that can take advantage of two different indexes. Also you have "AND" condition that Oracle tries to take advantage of using "BITMAP AND" operation. Since you like the performance of the plan that uses the BITMAP conversion, I can say that index "'AIF.AIF_OUTBOUND_IX01" is more selective than "'AIF.AIF_OUTBOUND_IX03" And in the second plan that one that does not use the BITMAP, if you force it to use index IX01, it would be faster. Degree has nothing to do to the index performance except when doing Index FFS. Regards, Waleed -Original Message-From: Fedock, John (KAM.RHQ) [mailto:[EMAIL PROTECTED]Sent: Wednesday, October 15, 2003 12:50 PMTo: Multiple recipients of list ORACLE-LSubject: bitmap conversion on a index that is not bitmapped ??? Platform is 8.1.7.4, HP-UX 11.00 I have a complex view. After rebuilding all indexes this weekend, the view got much faster. I did a trace on it. Now, a few days later, the view is getting much slower. Yes, an analyze has run since then, doing an 'estimate statistics', but an estimate stats was done after the rebuilds as well. The difference in the explain is below - please note that bitmapped conversion info (in bold): Good plan: ..67 .FIRST ROW..66 ..VIEW OF 'GAPP_USER. (CARD=1 BYTES=13 )..65 ...SORT (AGGREGATE) (CARD=1 BYTES=121 )..64 NESTED LOOPS (COST=53 CARD=1 BYTES=121 )..61 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.AIF_OUTBOUND' (COST=51 CARD=1 BYTES=86 )..60 ..BITMAP CONVERSION (TO ROWIDS)..59 ...BITMAP AND..55 BITMAP CONVERSION (FROM ROWIDS)..54 .INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX03' (NON-UNIQUE) (COST=4 )..58 BITMAP CONVERSION (FROM ROWIDS)..57 .SORT (ORDER BY)..56 ..INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX01' (NON-UNIQUE) (COST=11 )..63 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.EDI_ROUTE' (COST=1 CARD=65 BYTES=2275 )..62 ..INDEX (UNIQUE SCAN) OF 'AIF.EDI_ROUTE_PK' (UNIQUE) (CARD=65 ) Bad plan: ..61 .FIRST ROW..60 ..VIEW OF 'GAPP_USER. (CARD=1 BYTES=13 )..59 ...SORT (AGGREGATE) (CARD=1 BYTES=121 )..58 NESTED LOOPS (COST=52 CARD=1 BYTES=121 )..55 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.AIF_OUTBOUND' (COST=51 CARD=1 BYTES=86 )..54 ..INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX03' (NON-UNIQUE) (COST=3 CARD=1 )..57 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.EDI_ROUTE' (COST=1 CARD=65 BYTES=2275 )..56 ..INDEX (UNIQUE SCAN) OF 'AIF.EDI_ROUTE_PK' (UNIQUE) (CARD=65 ) The interesting thing is, the table in question does not have any bit mapped indexes on it. Some notes on MetaLink show other people questioning the same issue, but no concrete info is given. Any ideas out there? TIA. John John Fedock "K" Line America, Inc. www.kline.com * [EMAIL PROTECTED]
Re: bitmap conversion on a index that is not bitmapped ???
However, under Oracle 8.1.7, the default for _b_tree_bitmap_plans IS false. The default changes to true in Oracle 9, which is one of the reasons for plan differences when migrating to 9, not always for the better. Did the OP set _b_tree_bitmap_plans to true? At 01:39 PM 10/15/2003, you wrote: Missed one important point. You can disable that by setting _b_tree_bitmap_plans to FALSE. Deleting the stats may not be a right apporach as that may screwup some other plans. Sorry for missing the important one.. KG - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, October 15, 2003 10:39 PM > John: > > Optimizer is a smart boy!!! He knows the column has few distinct values > and decides the BITMAP access would be appropriate and making BITMAP > plans from the BTree indexes. If you delete the stats for that index, > you will get the old behavior. > > KG > > > > = > Have a nice day !! > > Best Regards, > K Gopalakrishnan, > Bangalore, INDIA. > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: K Gopalakrishnan > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: K Gopalakrishnan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Wolfgang Breitling Oracle7, 8, 8i, 9i OCP DBA Centrex Consulting Corporation http://www.centrexcc.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Wolfgang Breitling INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: bitmap conversion on a index that is not bitmapped ???
"Fedock, John (KAM.RHQ)" wrote: > > Stephan, > > That is correct. The old behavior is not what I want. I have rebuilt and > reanalyzed, deleted stats - tried all sorts of combinations and I cannot get it to > use the bitmapped access as it once did. Again - these are not bitmapped indexes to > begin with. > > John John, Interesting. Please understand that, as Gopal pointed out, thoes bitmapped indexes really are built 'on the fly' as a (as it appears, efficient) way to boost the query speed. The question, and I don't have the answer (but perhaps the eminent specialist of event 10053 on the list could shed some light) is what incites the optimizer to do this. Low cardinality is obviously a factor, but it cannot be the only one since I guess that the cardinality of your column musn't have changed much. This is a shot in the dark, but I'd certainly consider the clustering factor too. If keys with similar values are clustered, my guess is that bitmaps will contain big swathes of 1s or 0s or whatever, and Oracle will be able to pick lots of blocks of interest in one pass. If, however, the distribution of 'good' rows among 'bad' rows is pretty uniform, there is not much point in taking the trouble of building the bitmapped index. Would be interesting to play with the stats on a development database. HTH, SF > -Original Message- > Sent: Wednesday, October 15, 2003 4:29 PM > To: Multiple recipients of list ORACLE-L > > K Gopalakrishnan wrote: > > > > John: > > > > Optimizer is a smart boy!!! He knows the column has few distinct values > > and decides the BITMAP access would be appropriate and making BITMAP > > plans from the BTree indexes. If you delete the stats for that index, > > you will get the old behavior. > > > > KG > > > > = > > Have a nice day !! > > > > Best Regards, > > K Gopalakrishnan, > > Bangalore, INDIA. > > -- > > ... Unfortunately the old behaviour seems to be the bad one. I guess > that the solution would rather be to rebuild indexes on a regular basis > ... > > -- > Regards, > > Stephane Faroult > Oriole Software -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
UPDATE - bitmap conversion on a index that is not bitmapped ???
OK. How about this I checked the script for the index rebuilds. It did an 'alter index rebuild parallel 10 ...' After the rebuilds, we thought parallel 10 was not good, since Oracle cannot use PQO for a index read. We set the degree back to 1. Once a analyze was done, performance dropped. So as a test, I just set the degree 10 on the index, did an estimate statistics. Ran a plan, and it is now using the BITMAP conversion - which is great for performance. 2 questions remain: 1. This is not a bitmapped index! So how does this work? 2. How does the degree affect all of this? Obviously it does. Sorry for the rants, but this is very crazy in my opinion. TIA. John -Original Message- Sent: Wednesday, October 15, 2003 3:39 PM To: Multiple recipients of list ORACLE-L Missed one important point. You can disable that by setting _b_tree_bitmap_plans to FALSE. Deleting the stats may not be a right apporach as that may screwup some other plans. Sorry for missing the important one.. KG - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, October 15, 2003 10:39 PM > John: > > Optimizer is a smart boy!!! He knows the column has few distinct values > and decides the BITMAP access would be appropriate and making BITMAP > plans from the BTree indexes. If you delete the stats for that index, > you will get the old behavior. > > KG > > > > = > Have a nice day !! > > Best Regards, > K Gopalakrishnan, > Bangalore, INDIA. > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: K Gopalakrishnan > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: K Gopalakrishnan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Fedock, John (KAM.RHQ) INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: bitmap conversion on a index that is not bitmapped ???
Stephan, That is correct. The old behavior is not what I want. I have rebuilt and reanalyzed, deleted stats - tried all sorts of combinations and I cannot get it to use the bitmapped access as it once did. Again - these are not bitmapped indexes to begin with. John -Original Message- Sent: Wednesday, October 15, 2003 4:29 PM To: Multiple recipients of list ORACLE-L K Gopalakrishnan wrote: > > John: > > Optimizer is a smart boy!!! He knows the column has few distinct values > and decides the BITMAP access would be appropriate and making BITMAP > plans from the BTree indexes. If you delete the stats for that index, > you will get the old behavior. > > KG > > = > Have a nice day !! > > Best Regards, > K Gopalakrishnan, > Bangalore, INDIA. > -- ... Unfortunately the old behaviour seems to be the bad one. I guess that the solution would rather be to rebuild indexes on a regular basis ... -- Regards, Stephane Faroult Oriole Software -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Fedock, John (KAM.RHQ) INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: bitmap conversion on a index that is not bitmapped ???
K Gopalakrishnan wrote: > > John: > > Optimizer is a smart boy!!! He knows the column has few distinct values > and decides the BITMAP access would be appropriate and making BITMAP > plans from the BTree indexes. If you delete the stats for that index, > you will get the old behavior. > > KG > > = > Have a nice day !! > > Best Regards, > K Gopalakrishnan, > Bangalore, INDIA. > -- ... Unfortunately the old behaviour seems to be the bad one. I guess that the solution would rather be to rebuild indexes on a regular basis ... -- Regards, Stephane Faroult Oriole Software -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: bitmap conversion on a index that is not bitmapped ???
Missed one important point. You can disable that by setting _b_tree_bitmap_plans to FALSE. Deleting the stats may not be a right apporach as that may screwup some other plans. Sorry for missing the important one.. KG - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Wednesday, October 15, 2003 10:39 PM > John: > > Optimizer is a smart boy!!! He knows the column has few distinct values > and decides the BITMAP access would be appropriate and making BITMAP > plans from the BTree indexes. If you delete the stats for that index, > you will get the old behavior. > > KG > > > > = > Have a nice day !! > > Best Regards, > K Gopalakrishnan, > Bangalore, INDIA. > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: K Gopalakrishnan > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: K Gopalakrishnan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: bitmap conversion on a index that is not bitmapped ???
John: Optimizer is a smart boy!!! He knows the column has few distinct values and decides the BITMAP access would be appropriate and making BITMAP plans from the BTree indexes. If you delete the stats for that index, you will get the old behavior. KG = Have a nice day !! Best Regards, K Gopalakrishnan, Bangalore, INDIA. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: K Gopalakrishnan INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
bitmap conversion on a index that is not bitmapped ???
Platform is 8.1.7.4, HP-UX 11.00 I have a complex view. After rebuilding all indexes this weekend, the view got much faster. I did a trace on it. Now, a few days later, the view is getting much slower. Yes, an analyze has run since then, doing an 'estimate statistics', but an estimate stats was done after the rebuilds as well. The difference in the explain is below - please note that bitmapped conversion info (in bold): Good plan: ..67 .FIRST ROW..66 ..VIEW OF 'GAPP_USER. (CARD=1 BYTES=13 )..65 ...SORT (AGGREGATE) (CARD=1 BYTES=121 )..64 NESTED LOOPS (COST=53 CARD=1 BYTES=121 )..61 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.AIF_OUTBOUND' (COST=51 CARD=1 BYTES=86 )..60 ..BITMAP CONVERSION (TO ROWIDS)..59 ...BITMAP AND..55 BITMAP CONVERSION (FROM ROWIDS)..54 .INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX03' (NON-UNIQUE) (COST=4 )..58 BITMAP CONVERSION (FROM ROWIDS)..57 .SORT (ORDER BY)..56 ..INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX01' (NON-UNIQUE) (COST=11 )..63 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.EDI_ROUTE' (COST=1 CARD=65 BYTES=2275 )..62 ..INDEX (UNIQUE SCAN) OF 'AIF.EDI_ROUTE_PK' (UNIQUE) (CARD=65 ) Bad plan: ..61 .FIRST ROW..60 ..VIEW OF 'GAPP_USER. (CARD=1 BYTES=13 )..59 ...SORT (AGGREGATE) (CARD=1 BYTES=121 )..58 NESTED LOOPS (COST=52 CARD=1 BYTES=121 )..55 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.AIF_OUTBOUND' (COST=51 CARD=1 BYTES=86 )..54 ..INDEX (RANGE SCAN) OF 'AIF.AIF_OUTBOUND_IX03' (NON-UNIQUE) (COST=3 CARD=1 )..57 .TABLE ACCESS (BY INDEX ROWID) OF 'AIF.EDI_ROUTE' (COST=1 CARD=65 BYTES=2275 )..56 ..INDEX (UNIQUE SCAN) OF 'AIF.EDI_ROUTE_PK' (UNIQUE) (CARD=65 ) The interesting thing is, the table in question does not have any bit mapped indexes on it. Some notes on MetaLink show other people questioning the same issue, but no concrete info is given. Any ideas out there? TIA. John John Fedock "K" Line America, Inc. www.kline.com * [EMAIL PROTECTED]
