We have an ORACLE 10g standard edition 1

I have a HEAP organized table of ~ 6 million records. Doing a select count with full table scan i get:
consistent gets: 29511, and the duration is somewhere about 5 seconds

After moving the table to IOT ( nevermind the reasons behind the decision) the same select count will need:
consistent gets: 120 000
and will need somewhere about 13 seconds.

The number of CG is normal ( analyzing the index returns about 120 000 blocks)

interesting is that the wait event on the active session doing the IOT query is “db sequential read”, instead of “db scattered read”, which leads me to the following question:

full table scans are known to do scattered reads, taking advantage of the multiblock read.
index organized tables, due to their organization, will always follow an index fast full scan to process the query, but: it is also said that only oracle enterprise edition can do parallel index scans.

Does that mean that standard edition can do scattered read on full table scan, but not on fast full scan of indexes ?

I have not found a concrete answer to this question yet, and it would be really helpful (for the community also, i am sure) to know this. Would really appreciate your time on this one.

Thank you
Alex

There are all sorts of options available to the human that the optimizer code cannot see – this just happens to be a simple and obvious example of the principle. You are perfectly correct that this is a shortcoming of the CBO, and with a little luck it might be one that can be removed relatively easily.

My point is that if the CBO can do an ‘Index Full scan’ without touching the table, then it should be able to do an ‘Index Fast Full scan’ as well. If it discards that path, then I think that this is a shortcoming of the CBO (unless there is a sound reason which I am not getting).

I have included the predicate section in the plans.

Greg Rahn has commented that he will check if the restriction can be lifted.

Many thanks,
CJ

The index fast full scan is only available to the optimizer if all columns referenced in the query are in the index.
Even though it’s obvious to the human eye that your predicate is always true and therefore redundant, and even though the optimizer eventually eliminates it (which we would be able to see from the predicate section if you had printed it in the OTN posting), the optimizer has already discarded the index_ffs before it considers the predicate elimination.

I don’t know if everyone is affected, but I get an error page when logging on to OTN at present (but not when logging on to MOS) – so perhaps someone else has been waiting to answer the questioon for you,but has been able to log on.

I have posted a question about fast full scans of local nonprefixed index, but surprisingly (for me) nobody has replied yet.

Could I request you to take a quick look and give your opinion (even if it is to flame me for a daft question)?

http://forums.oracle.com/forums/message.jspa?messageID=9794705#9794705

Many thanks,
CJ

I haven’t checked for changes in 10g, but the basic arithmetic used to be the same as that used for tablescans, except for using the leaf_blocks figure from dba_indexes instead of the blocks figure from dba_tables. This is documented in Cost Based Oracle – Fundamentals.

Would like to know the formula behind the index fast full scan especially with OICA & OIC value for the Global & Local Partitioned Index. Trying to correlate with 10053 trace but I still couldnt get thro’..

Appreciate your inputs..

Version : 10.2.0.3 / No Histograms / Bind Variables / 2 Tables Joins

Thanks.