RE: Accessing ASH is slow
Date: Tue, 23 Jul 2013 18:48:20 -0400
Message-ID: <045001ce87f6$bbc00030$33400090$_at_rsiz.com>
Because the NLS_COMP (comparison) value was set to LINGUISTIC, so Oracle translates the join condition for you to use linguistic equivalent rather than binary values. This allows for binary values that map to equivalent values in some language to evaluate as equals. For purposes of the values in NEED_SAMPLE this probably never makes a difference to the answer, but Oracle injects the change to processing views nonetheless.
The Oracle Database Globalization Support Guide has some information about this, and the Oracle Database SQL Language Reference has information about how the NLSSORT function operates.
mwf
From: Henry Poras [mailto:hrp_at_google.com]
Sent: Tuesday, July 23, 2013 4:45 PM
To: Mark W. Farnham
Cc: usn_at_usn-it.de; ORACLE-L
Subject: Re: Accessing ASH is slow
but why should the join condition even apply the NLSSORT function?
On Tue, Jul 23, 2013 at 4:36 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:
It should not affect the answer (except possibly the ordering of the reported set), but it can affect whether or not an index can be used in projecting the join.
From: Henry Poras [mailto:hrp_at_google.com]
Sent: Tuesday, July 23, 2013 3:13 PM
To: mwf_at_rsiz.com
Cc: usn_at_usn-it.de; ORACLE-L
Subject: Re: Accessing ASH is slow
Martin,
Maybe I'm missing something here, but why would the NLSSORT setting impact the join condition? Wouldn't the outcome of the join equality be the same regardless of the sort setting?
Henry
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jul 24 2013 - 00:48:20 CEST