| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: 9i on RHAS3
Read operation from even one-ROW table will benefit from index -> if you index all necessary columns. A full table scan reads segment header and the datablock. Index scan requires only one read of leaf block in case of one-block index.
Also, you may get other benefits, if you have unique index or constraint on the table, Oracle won't search for more rows once first one is retrieved - and in join condition these one-row row sources can be put first in join order, helping in performance.
Tanel.
If the question is 'Should I use an index with a small table, even \ one that fits in a single block", then the answer is very possibly "yes".
Best to test with your SQL, but for simple selects the use of an index makes the SQL much more scalable.
Search the archives on 'run_stats', as that was the name of a script used to compare indexed vs. non-indexed.
Jared
"Jesse, Rich" <Rich.Jesse_at_qtiworld.com>
Sent by: ml-errors_at_fatcity.com
10/31/2003 01:09 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: RE: 9i on RHAS3
Wasn't there a whitepaper somewhere that said that it may be more efficient to use an index with NL, even if the entire table fits in a single block? A quick scan of my saved ORACLE-L messages didn't reveal anything.
Rich
Rich Jesse System/Database Administrator rjesse_at_qtiworld.com Quad/Tech Inc, Sussex, WI USA
> -----Original Message-----
> From: Mladen Gogala [mailto:mladen_at_wangtrading.com]
> Sent: Friday, October 31, 2003 11:25 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: 9i on RHAS3
>
>
> Rich, I don't have AS 3.0, I'm using regular RH 9 and RH 8
> based worsktations, with gcc 3.2
> (gcc-gnat-3.2.2-5,gcc-3.2.2-5) and curiously enough, the
> installation worked right out of
> the box, with a quirk with linking context ("undefined
> symbol"), but I was able to ignore the
> error and proceed. Oracle works well, no complaints so far.
> There is a thing that confuses me,
> but it's generic. I tried on a Solaris8 box and the result
> was the same (9.2.0.4). Here is
> what confuses me. Here are two execution plans, for the same
> query (autotrace on explain, timing on).
> More expensive plan takes less time. Shouldn't it be the
> other way round?
> Elapsed: 00:00:00.00
>
> Execution Plan
> ----------------------------------------------------------
> 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=7 Card=14 Bytes=77
> 0)
>
> 1 0 NESTED LOOPS (Cost=7 Card=14 Bytes=770)
> 2 1 TABLE ACCESS (BY INDEX ROWID) OF 'CP_ACTIONS' (Cost=2 Ca
> rd=14 Bytes=588)
>
> 3 2 INDEX (RANGE SCAN) OF 'CP_ACTIONS_EFF_I' (NON-UNIQUE)
> (Cost=2 Card=14)
>
> 4 1 TABLE ACCESS (BY INDEX ROWID) OF 'CHG_TKR' (Cost=2 Card=
> 1 Bytes=13)
>
> 5 4 INDEX (UNIQUE SCAN) OF 'SYS_C004800' (UNIQUE) (Cost=1
> Card=1)
>
>
> Elapsed: 00:00:00.01
>
> Execution Plan
> ----------------------------------------------------------
> 0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=6 Card=14 Bytes=77
> 0)
>
> 1 0 HASH JOIN (Cost=6 Card=14 Bytes=770)
> 2 1 TABLE ACCESS (BY INDEX ROWID) OF 'CP_ACTIONS' (Cost=2 Ca
> rd=14 Bytes=588)
>
> 3 2 INDEX (RANGE SCAN) OF 'CP_ACTIONS_EFF_I' (NON-UNIQUE)
> (Cost=2 Card=14)
>
> 4 1 TABLE ACCESS (FULL) OF 'CHG_TKR' (Cost=4 Card=1602 Bytes
> =20826)
>
>
>
>
> > Has anyone tried 9i on RHAS3 yet? Metalink 252217.1 and
> the venerable
> > Werner Puschitz's site http://www.puschitz.com have many
> icky hacks that
> > seem to have to be done, including temporarily dropping
> gcc323 to the highly
> > unstable and buggy v2.96 (even GNU says not to use it! --
> it's not even
> > listed as a release on their website).
> >
> > I'm guessing that Mr. Puschitz isn't on this list? Looks
> like he knows the
> > Oracle install on RedHat quite well.
> >
> > How's about it, Mladen? I'm not willing to scrap my Gentoo
> box to test it.
> > :)
> >
> >
> > Rich
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jesse, Rich
INET: Rich.Jesse_at_qtiworld.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).Received on Sat Nov 01 2003 - 05:39:47 CST
 |
 |