I don't have any scientific proof but I imagine the sort_area_size could be
different between "not exists" and "minus".  When doing "minus" the entire
select string would have to be compared for equality, which could be very
large depending on your string.

Minus is probably an easier way (at least from a coding perspective) of
comparing every column in a table, or incorporating complexity in the
select statement.

Having said that.  Each statement has it's pros and cons and I guess it
depends on the volume of the various queries, etc.  For example, if the
have table A with 5 rows and table B with 1000000 rows executing "select
a.field from a where not exists (select 1 from b where b.field = a.field)
will result in 5 quick searches (assuming b.field is indexed) whereas
"select a.field from a where a.field not in (select b.field from b)" will
result in a full index read of b, as would "select a.field from a minus
select b.field from b".  Obviously different queries and different volumes
will tip the scales in different directions.

Regards,
      Mark.



                                                                                       
                                               
                      "Ryan"                                                           
                                               
                      <[EMAIL PROTECTED]        To:       Multiple recipients of list 
ORACLE-L <[EMAIL PROTECTED]>                  
                      >                        cc:                                     
                                               
                      Sent by:                 Subject:  minus vs. where not exists, 
vs. where not in                                 
                      [EMAIL PROTECTED]                                                
                                               
                      .com                                                             
                                               
                                                                                       
                                               
                                                                                       
                                               
                      22/09/2003 03:59                                                 
                                               
                      Please respond to                                                
                                               
                      ORACLE-L                                                         
                                               
                                                                                       
                                               
                                                                                       
                                               




Do any of you have any cases when minus is superior in performance? Ive
found 'not in' with a hash_aj to be the best option if the sub-query is
significantly less 'costly' then the outer query. I dont mean cost in terms
of the Explain Plan, I mean the work Oracle has to do to find a result set.
It also depends on a proper hash_area_size

I find 'where not exists' to be best if the subquery is relatively close in
cost to the outer query. Yes I know you cant make broad generalizations,
but there has to be some 'narrow' generalizations you can make. Such as
certain cases, etc...

what have you seen? There seems to be very little work in this area in the
literature.

Does 'where not exist' need more or less sort_area_size space than minus?


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   Privileged/Confidential information may be contained in this message.
          If you are not the addressee indicated in this message
       (or responsible for delivery of the message to such person),
            you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender
           by reply e-mail or by telephone on (61 3) 9612-6999.
   Please advise immediately if you or your employer does not consent to
                Internet e-mail for messages of this kind.
        Opinions, conclusions and other information in this message
              that do not relate to the official business of
                         Transurban City Link Ltd
         shall be understood as neither given nor endorsed by it.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>




<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message.
If you are not the addressee indicated in this message (or responsible for delivery of 
the message to such person), you may not copy or deliver this message to anyone.
In such a case, you should destroy this message and kindly notify the sender by reply 
e-mail or by telephone on (03) 9612-6999 or (61) 3 9612-6999.
Please advise immediately if you or your employer does not consent to Internet e-mail 
for messages of this kind.
Opinions, conclusions and other information in this message that do not relate to the 
official business of Transurban Infrastructure Developments Limited and CityLink 
Melbourne Limited shall be understood as neither given nor endorsed by them.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mark Richard
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to