RE: Long execute phase for SELECT query

You are correct Egor - there are actually 167 recursive queries (dep=1) in between the PARSE #9 and the EXEC #9, and when I add up the p and cr values of all 167 of them - the sum comes out to exactly p=41 and cr=804.

I'm pretty sure that the answer to my question is that the optimization is taking place during the EXECUTE phase instead of the PARSE phase, due to bind variable peeking - as described in Metalink note 199273.1, but if anyone thinks there is a better explanation, please let me know.

Thanks,
Brandon

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Egor Starostin

I'd say 'there were recursive calls'.
I.e. before first 'EXEC #9' there were several (or just one) PARSE/EXEC/FETCH'es with non-zero p's, cr's and dep > 0.

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.

--
http://www.freelists.org/webpage/oracle-l