On Wed, 13 Oct 2004 11:14:52 -0600, Wolfgang Breitling <breitliw@xxxxxxxxxxxxx> wrote: > Actually it looks as if 1 row is returned per execution: 3262 parses, 3262 > executes, 3262 fetches and 3262 rows returned. If it is correct that every D'oh! Yup, that was pretty obvious. Jared > At 10:45 AM 10/13/2004, Jared Still wrote: > >Yup, lots of parsing. > > > >If you eliminate all the parsing, you will have saved > >.32 seconds on a 3.78 second query. > > > >Do you think the user will notice? > > > >The query is spending 2.17 seconds retrieving 26472 rows > >of data, only 3262 of which you are using. > > > >26472 rows fetched / 120 fetches = 220 rows per block. > > > >3262 rows retrieved / 120 fetches = 27 rows per block > > > >The data being retrieved is fairly well scattered across the table. > > > >Perhaps a different index is in order? > > > >Or maybe the query is limited by the design of the table? > > > >Or the query is malformed? > > > >Anyway, reducing IO would be in order here if possible. > > > >Lots of maybes. > > > >You might consider running a 10046 trace on the user running > >this form, and find out where and why the time is being used. > > > >Tkprof does not provided sufficient detail other than what is > >needed to drive lots of speculation. :) > > > > Wolfgang Breitling > Oracle7, 8, 8i, 9i OCP DBA > Centrex Consulting Corporation > http://www.centrexcc.com > > > > -- > //www.freelists.org/webpage/oracle-l > -- Jared Still Certifiable Oracle DBA and Part Time Perl Evangelist -- //www.freelists.org/webpage/oracle-l