-----Original Message-----
From: Ali Zaidi
To: [EMAIL PROTECTED]
Sent: 06/26/2001 10:26 AM
Subject: Re: RE: Shorthand for $dbh->prepare and $sth->execute?
>Being an Oracle guy i can tell for sure the steps taken by
>Oracle
>Prepare: In this step Oracle parses your query and prepares the
>execution plan.
>Execute: In this step Oracle gets the data returned by your
>query into its memory area
All the data? I really doubt it, though I never tested myself. This would
seems very inefficient since if it fetches everything at execute, what
happens if you want to abort you query along the way. What's the point of
fetching everything at once, not knowing how many rows will be fetched. You
can probably set the cache to do that, but I would imaging that it caches a
reasonable amount of data to optimize the fetches, but not all the data
returned from a query.
Ilya
>Fetch: This is when the data is returned to the user process.
---- On Tue, 26 Jun 2001, Michael Peppler
([EMAIL PROTECTED]) wrote:
> Orlando Andico writes:
> > On Tue, 26 Jun 2001, Marcotullio, Angelo wrote:
> > ..
> > > In Oracle, the $sth->execute() builds the cursor and
waits for the
> program
> > > to start fetching records. The hints don't change this
behavior,
> just the
> > > access plan.
> > ..
> >
> > Hrmmm... that's not what I've seen. I wrote some code
which used
> > Time::HiRes to measure the time taken at each step..
something like
> this:
> >
> > $t0 = [gettimeofday];
> > $sth = $dbh->prepare ("SELECT * FROM
TEN_MILLION_ROW_TABLE");
> > print [gettimeofday] - $t0;
> >
> > $t0 = [gettimeofday];
> > $sth->execute;
> > # and so on..
> >
> > and definitely, the execute part took longest.. if what
you're saying
> is
> > true, execute would return immediately and let me fetch
records at
> will.
> > That does NOT happen. execute takes forever, THEN i can
fetch
> records.
>
> That's interesting - shouldn't such a select return *very*
quickly? It
> doesn't have to build a complex query plan, it just needs to
follow
> the page or row chain and return the rows in any order that
it wants
> to...
>
> Michael
> --
> Michael Peppler - Data Migrations Inc. - [EMAIL PROTECTED]
> http://www.mbay.net/~mpeppler - [EMAIL PROTECTED]
> International Sybase User Group - http://www.isug.com
> *Looking for new project to tackle starting 8/1/01*
>
>
________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
