Re: Performance Issue

From: Ed Stevens <spamdump_at_nospam.noway.nohow>
Date: Tue, 03 Sep 2002 12:24:21 GMT
Message-ID: <3d74a948.2095573_at_ausnews.austin.ibm.com>


The first thing that comes to my mind is that since the 'fast' table only has 4 columns copied from the 'slow' table, it has much less data, thus probably requires fewer block reads.

It could also be a difference in statistics, or indexing, or . . .

[Quoted] You're compareing apples and oranges.

On Tue, 3 Sep 2002 12:42:06 +0100, "TC3 Racer" <gordonchapman_at_hotmail.com> wrote:

>I have a table that a select Count(*) .... takes 5-10 secs
>A table that is a copy of this with only 4 columns of the above comes back
>instantly.
>
>Full Table
>
> DOUBLE_METAPHONE NOT NULL VARCHAR2(50)
> ORIGINAL_STRING NOT NULL VARCHAR2(50)
> PHONETIC_STRING VARCHAR2(100)
> POI_TYPE NOT NULL VARCHAR2(50)
> ROAD_NAME VARCHAR2(100)
> TOWN_NAME VARCHAR2(50)
> COUNTY_NAME VARCHAR2(50)
> SRS_NAME NOT NULL VARCHAR2(50)
> X_COORDINATE NOT NULL NUMBER
> Y_COORDINATE NOT NULL NUMBER
> SEGMENT_ID NOT NULL NUMBER(38)
> ROAD_MATCH NOT NULL NUMBER(1)
> PRIORITY_LEVEL NOT NULL NUMBER(2)
>
> Copy of
>
> NAME NOT NULL VARCHAR2(50)
> TYPE NOT NULL VARCHAR2(50)
> X NOT NULL NUMBER
> Y NOT NULL NUMBER
>
> Any suggestions as to what the possible problem could be or what i should
>do to investigate further
>
> Many Thanks
>
> GC
>
>
>
>
>

--
Ed Stevens
(Opinions expressed do not necessarily represent those of my employer.)
Received on Tue Sep 03 2002 - 14:24:21 CEST

Original text of this message