|
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.
----- Original Message -----
Sent: Saturday, November 01, 2003 12:09
AM
Subject: RE: 9i on RHAS3
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"
<[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
10/31/2003 01:09 PM
Please respond to ORACLE-L
|
To:
Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
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
[EMAIL PROTECTED]
Quad/Tech Inc, Sussex, WI USA
>
-----Original Message-----
> From: Mladen Gogala
[mailto:[EMAIL PROTECTED]
> 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: [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).
|
