RE: Long execute phase for SELECT query
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: <egorst@xxxxxxxxx>, "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
- Date: Wed, 28 Jun 2006 13:14:49 -0700
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
