Re: index full scan over an index fast full scan in an analytic function?

Hi!

As an addition to Vladimir's response:

Full scan will search from index root block using branch blocks to first leaf block. And since all leaf blocks have pointers to next and previous leaf block in index, sequentially reading only leaf blocks is sufficient for returning all values in index, in order (keys are ordered inside leaf blocks as well).

FFS will scan from index header block (note that index segment header and index root block are different ones) up to segment high water mark using multiblock reads and ignoring contents of root, branch, bitmap, extent map, freelist group blocks. Rows are returned as they've read from blocks, thus no order can be guaranteed.

Tanel.

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Friday, October 24, 2003 8:39 AM function?

> Mladen
>
> Mladen Gogala wrote:
> > B*tree indexes are ALWAY ordered. That's the way they're created and
> > searched.
> > I don't know the difference between full index scan and fast full index
> > scan. I know that the latter is used when the tble rows are not needed.
>
> It's an excerption from "Oracle8i Designing and Tuning for Performance
Release
> 2", 4 The Optimizer.
>
> "
> Full scan
> This is available if a predicate references one of the columns in the
index.
> The predicate does not need to be an index driver. Full scan is also
available
> when there is no predicate, if all of the columns in the table referenced
in
> the query are included in the index and at least one of the index columns
is
> not null. Full scan can be used to eliminate a sort operation. It reads
the
> blocks singly.
>
> Fast full scan
> This is an alternative to a full table scan when the index contains all
the
> columns that are needed for the query, and at least one column in the
index
> key has the NOT NULL constraint. Fast full scan accesses the data in the
index
> itself, without accessing the table. It cannot be used to eliminate a sort
> operation. It reads the entire index using multiblock reads (unlike a full
> index scan) and can be parallelized.
>
> Fast full scan is available only with the CBO. You can specify it with the
> initialization parameter OPTIMIZER_FEATURES_ENABLE or the INDEX_FFS hint.
> Fast full index scans cannot be performed against bitmap indexes.
> "
> --
> Vladimir Begun
> The statements and opinions expressed here are my own and
> do not necessarily represent those of Oracle Corporation.
>
> > Sounds like
> > both methods are reading all leaf blocks, from start to finish, using
> > multiblock read. I am not aware of any difference between the two
methods.
> > This sounds like a question for asktom or ixora (Tom Kyte or Steve
Adams).
> > Wolfgang Breitling and J. Lewis might also know.
> >
> > On 2003.10.23 23:14, Larry Elkins wrote:
> >
> >> Because when doing an index range scan things are read ordered? Very
> >> different from an index fast full scan where blocks are simply grabbed
> >> where
> >> they might lie?
> >>
> >> Regards,
> >>
> >> Larry G. Elkins
> >> The Elkins Organization Inc.
> >> elkinsl_at_flash.net
> >> 214.954.1781
> >>
> >> > -----Original Message-----
> >> > From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com]On Behalf
Of
> >> > Ryan
> >> > Sent: Thursday, October 23, 2003 9:34 PM
> >> > To: Multiple recipients of list ORACLE-L
> >> > Subject: Re: index full scan over an index fast full scan in an
> >> analytic
> >> > function?
> >> >
> >> >
> >> > why would you not need a sort with a full index scan and need one
> >> with a
> >> > fast full scan?
> >> > ----- Original Message -----
> >> > To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> >> > Sent: Thursday, October 23, 2003 5:19 PM
> >> > function?
> >> >
> >> >
> >> > > Possibly to avoid a sort operation (assuming that you might be
> >> > able to get
> >> > > away with a NOSORT when doing the full index scan)? It might be
> >> deciding
> >> > > that the benefit of the multi-block reads for the fast full
> >> > scan are more
> >> > > than offset by the sort operation that would be needed (and might
> >> not be
> >> > > needed when doing the full index scan).
> >> > >
> >> > > Regards,
> >> > >
> >> > > Larry G. Elkins
> >> > > The Elkins Organization Inc.
> >> > > elkinsl_at_flash.net
> >> > > 214.954.1781
> >> > >
> >> > > > -----Original Message-----
> >> > > > From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com]On
> >> Behalf Of
> >> > > > rgaffuri_at_cox.net
> >> > > > Sent: Thursday, October 23, 2003 2:39 PM
> >> > > > To: Multiple recipients of list ORACLE-L
> >> > > > Subject: Re: index full scan over an index fast full scan in
> >> > an analytic
> >> > > > function?
> >> > > >
> >> > > >
> >> > > > i cant attach the 10053 trace. it has proprietary info. There
> >> > > > isnt much in analytic explain plan either.
> >> > > >
> >> > > > does anyone know in general why a full scan would be faster than
> >> > > > a fast full scan?
> >> > > > >
> >> > > > > From: <rgaffuri_at_cox.net>
> >> > > > > Date: 2003/10/23 Thu PM 03:09:26 EDT
> >> > > > > To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> >> > > > > Subject: index full scan over an index fast full scan in an
> >> > > > analytic function?
> >> > > > >
> >> > > > > I have an index on the two columns used in this query. Why
> >> > > > would the optimizer choose an index full scan over an index fast
> >> > > > full scan?
> >> > > > >
> >> > > > > My question isnt why an index is used, but the type of index
> >> scan?
> >> > > > >
> >> > > > > select *
> >> > > > > from (select col1, col2,
> >> > > > > dense_rank()
> >> > > > > over (partition by col1
> >> > > > > order by col2 desc)tab
> >> > > > > from mytable)
> >> > > > > where tab = 1
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Vladimir Begun
> INET: vladimir.begun_at_oracle.com
>
> 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: ListGuru_at_fatcity.com (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: Tanel Poder
  INET: tanel.poder.003_at_mail.ee

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: ListGuru_at_fatcity.com (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).