Oracle seems to do 90% of the work before execute() returns, but it still
hasn't necessarily counted all the rows. The big difference between
fetchall* and fetching a row at a time is that until you fetch them, the
rows are in Oracle's memory and disk space, not your program's memory. That
is probably not a big difference for a few thousand rows, but when you are
processing larger sets it can be significant.
--
Mac :})
** I normally forward private questions to the appropriate mail list. **
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.
----- Original Message -----
From: "Orlando Andico" <[EMAIL PROTECTED]>
To: "Marcotullio, Angelo " <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, June 26, 2001 08:48
Subject: RE: Shorthand for $dbh->prepare and $sth->execute?
> 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.
>
> note that my select is brain-dead simple, uses no indexes, etc.. =)
> of course this is an extreme case.. its not often one would want to fetch
> every row from a 10-million-row table..
