See Perl DBI, page 111.
"In response to the execute() earlier, the database may do no more than set
a pointer, known as a cursor, to just above the first row of the table.
To extract the results data from the database, you need to explicitly fetch
them. This is the third stage in the cycle." (prepare, execute, fetch)
This is what I see in my Oracle environments with many 100+ million row
tables.
Do you see i/o on the datafiles during your execute()?
-----Original Message-----
From: Orlando Andico [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 26, 2001 11:49 AM
To: Marcotullio, Angelo
Cc: ''[EMAIL PROTECTED] ' '
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..
--
Orlando Andico <[EMAIL PROTECTED]>
Mosaic Communications, Inc.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GE d(-) s: a-25 C++++ UBLSI++++$ P+++ L+++>++++ E- W++ N(+)
o K? w O-- M- !V PS(++) PE- Y PGP-- t(+)@ 5(+) X++@ R(+) tv@
b++ DI++ G e++@ h--(*) r% y+
------END GEEK CODE BLOCK------
