Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Advice please "NOT IN" query takes ages! 3

Status
Not open for further replies.

Welshbird

IS-IT--Management
Jul 14, 2000
7,378
DE
I have two tables that I load just in order to find which records appear in one and not in the other (its purely a validation process).

I thought I was making it easier but concatenating the three columns (in each table) into one called "KEY", indexing the KEY field in each, and then running a basic
Code:
select * from BIGTABLE where key not in
(select key from SMALLERTABLE)
Each table has about 2.3 million records, but it still seems to take f'rages.

I do recall someone telling me that a 'not in' is not very efficient, so which is the best way for me to deal with this then?

Thanks chaps.

Fee

The question should be [red]Is it worth trying to do?[/red] not [blue] Can it be done?[/blue]
 
Do you have an index of any sort on key in smallertable ?
 
KEY is indexed in both tables.

Fee

The question should be [red]Is it worth trying to do?[/red] not [blue] Can it be done?[/blue]
 
After 1 hour and 12 minutes (and still no result) I tried the following instead:
Code:
select master.* from master
left join teams on (master.key = teams.key)
where teams.key is null;
And I have results almost instantly.

Can someone explain to my why this happens?

Fee

The question should be [red]Is it worth trying to do?[/red] not [blue] Can it be done?[/blue]
 
The best thing would be to get an explain plan for both queries. The most likely scenario is that Oracle is doing the first one using nested loops full table scans i.e for each row in master it is doing a full table scan of teams.

The only drawback of a join rather than "not in" or "not exists" is that there could be duplicates in the teams table, which would result in duplicates in the output. An alternative would be to use "not exists":

select * from master m
where not exists
(select 1 from teams t
where t.key = m.key)

You should also make sure that stats are up to date on both tables.
 
Thanks for that Dagon - that ran just as quickly as the one I tried, and gave the same number of rows.

In this case I know from the data source that there cannot be duplicates, but its' good to know how I would deal with them in another situation.

Fee

The question should be [red]Is it worth trying to do?[/red] not [blue] Can it be done?[/blue]
 
My DBA has told me repeatedly that the ORACLE MINUS command is very efficient.

SELECT * FROM bigtable WHERE key IN
(SELECT key FROM bigtable MINUS SELECT key FROM smallertable)


-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
 
I agree:

SELECT key FROM bigtable MINUS SELECT key FROM smallertable

is usually quite efficient. I am less convinced that putting into a subquery would be a good idea.
 
Generally speaking, the MINUS construct would be more efficient, particularly for large data sets.

Regarding the original query, you may get better results with
Code:
select * from BIGTABLE where key NOT EXISTS
(select key from SMALLERTABLE);
but the left outer join or set operation will still be more likely to give you the performance you seek.

 
Well I've never heard of a MINUS thing before. Ah the joys of a three days in Oracle once... and that was it.

Thanks guys.
star.gif
's all round.

Fee

The question should be [red]Is it worth trying to do?[/red] not [blue] Can it be done?[/blue]
 
Dave (Carp), I believe the NOT EXISTS code would have to syntactically read something like this to work:
Code:
select * from BIGTABLE x where NOT EXISTS
(select 'anything' from SMALLERTABLE y
  where x.key = y.key);
Let me know if I'm off base.


[santa]Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
 
YOU - off base? Yeah, THAT'LL be the day!
Nope - I was just doing a quick drive by and hosed up.
Thanks for the correction.
 
LOL, the great and powerful wizard of oracle being wrong.... HA, not very darn often!!!!

Bill
Oracle DBA/Developer
New York State, USA
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top