Re: where 1=2
Date: Mon, 29 Jun 2015 21:32:59 +0200
Message-ID: <CABz5TyAzKdy0-fvYkUJ3KeyyR6NtT1=nYt0rD8rjS95rb38YwA_at_mail.gmail.com>
Yes, that was a simplified version of the query
I did change cursor_sharing and it behaves identical now in all databases.
Thanks for pointing me into right direction (and I can now assume the reason it worked to trick the db into FTS in earlier version was that the optimizer couldn't optimize away this from the execution plan)
On Mon, Jun 29, 2015 at 9:23 PM, Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk
> wrote:
>
> That's correct - although the appearance of the internal_function() also
> suggests that there may be a further oddity to pursue (or that your c1 =
> '1' example was an over simplification).
>
>
>
> Regards
> Jonathan Lewis
> http://jonathanlewis.wordpress.com
> _at_jloracle
> ------------------------------
> *From:* Johan Eriksson [valpis_at_gmail.com]
> *Sent:* 29 June 2015 19:53
> *To:* Jonathan Lewis
> *Cc:* knecht.stefan_at_gmail.com; oracle-l-freelists
> *Subject:* Re: where 1=2
>
> from the v$sql_plan on 11.2.0.4
> (:SYS_B_0<>:SYS_B_1 OR
> INTERNAL_FUNCTION("YFS_ORDER_LINE"."ORDER_LINE_KEY"))
>
> Since that indicates that 1!=1 is present I did check the cursor_sharing
> on 11.2.0.3 : EXACT
> 11.2.0.4: FORCE
>
> which I think might explain the issue
>
> On Mon, Jun 29, 2015 at 8:44 PM, Jonathan Lewis <
> jonathan_at_jlcomp.demon.co.uk> wrote:
>
>>
>> Since you can query ASH I assume you can also get the runtime execution
>> plan.
>> What do the two predicate sections say.
>> If it's not cost the next obvious guess is NLS conversion or some other
>> coercion issue.
>>
>>
>>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Jun 29 2015 - 21:32:59 CEST