RE: what could cause a high elap value for the exec system call (for a select statement)?

Am I correct to say that, for a select statement, the exec call includes all the work (except parsing) that needs to be done to construct the cursor and that the fetch call includes all the work that needs to be done to retrieve rows from that cursor?

Regards,  

Freek D'Hooge
Uptime
Oracle Database Administrator
email: freek.dhooge_at_uptime.be
tel +32(0)3 451 23 82
http://www.uptime.be
disclaimer: www.uptime.be/disclaimer

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham Sent: woensdag 4 november 2009 14:47
To: D'Hooge Freek; 'Daniel Fink'; tim_at_evdbt.com; Brandon.Allen_at_OneNeck.com Cc: 'Oracle-L_at_freelists.org'
Subject: RE: what could cause a high elap value for the exec system call (for a select statement)?

I'm pretty sure Tim meant that in the context a whole heck of a lotta work must occur before you know what the first row to return is.

Another example is if you have a union (non-all) and the source datasets of the parts of the union don't have a provable joint subkey, then you have to do full projection of all the columns in the parts of the queries and sort the resultset for duplicate rejection before you return anything. Something like that with 1000 columns in the select list would be a really bad joke to play on a computer system.

Please do correct me if I got that wrong, Tim.

mwf
--

http://www.freelists.org/webpage/oracle-l Received on Wed Nov 04 2009 - 08:07:44 CST