Explain my Explain Plans please?

Question

Hi,
I have two schema's situated on the same database. One called SCHEMA_A_LIVE and another SCHEMA_B_LIVE. Both schemas have been analyses for stats, however SCHEMA_B_LIVE doesn't hold any data where as SCHEMA_A_LIVE does. They both essentially have the same tables, indexes, tablespaces, structure, etc but when I run an Explain plan in TOAD for a SQL statement take from the same procedure in both schemas, I receive different plans? SCHEMA_A_LIVE returns a NESTED LOOPS and SORT UNIQUE and SCHEMA_B_LIVE returns a HASH SEMI JOIN (not sure what this is either???). Can someone please explain why I getting different results and as well as the pros/cons of each plan?
SQL:
DELETE FROM "SCHEMA_A_LIVE".CHANGE_HISTORY
WHERE TOID IN(SELECT TOID FROM "SCHEMA_A_LIVE".LOADER_CHANGEHISTORY);
EXPLAIN PLAN:
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
DELETE STATEMENT Optimizer Mode=ALL_ROWS          1           4.00140839118856                     
DELETE     SCHEMA_A_LIVE.CHANGE_HISTORY                                   
NESTED LOOPS          1      47      4.00140839118856                     
SORT UNIQUE          1      10      2.00065584594569                     
TABLE ACCESS FULL     SCHEMA_A_LIVE.LOADER_CHANGEHISTORY     1      10      2.00065584594569                     
INDEX RANGE SCAN     SCHEMA_A_LIVE.PK_CHANGEHISTORY     1      37      1.00075254524288                     
SQL:
DELETE FROM "SCHEMA_B_LIVE".CHANGE_HISTORY
WHERE TOID IN(SELECT TOID FROM "SCHEMA_B_LIVE".LOADER_CHANGEHISTORY);
EXPLAIN PLAN:
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
DELETE STATEMENT Optimizer Mode=ALL_ROWS          1           2.50067886958788                     
DELETE     SCHEMA_B_LIVE.CHANGE_HISTORY                                   
HASH JOIN SEMI          1      50      2.50067886958788                     
INDEX FULL SCAN     SCHEMA_B_LIVE.PK_CHANGEHISTORY     1      40                          
TABLE ACCESS FULL     SCHEMA_B_LIVE.LOADER_CHANGEHISTORY     1      10      2.00065584594569                     
Both have the following index:
Enter value for 1: change_history
INDEX_NAME UNIQUENES COLUMN_POSITION COLUMN_NAME
PK_CHANGEHISTORY UNIQUE 1 TOID
PK_CHANGEHISTORY 2 VERSION
PK_CHANGEHISTORY 3 CHANGEDATE
PK_CHANGEHISTORY 4 REASONFORCHANGE
Thanks,
Tony

Answer 1

The resulting explain plan is as follows:
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
DELETE STATEMENT Optimizer Mode=ALL_ROWS          1           0                     
DELETE     SCHEMA_B_LIVE.CHANGE_HISTORY                                   
NESTED LOOPS SEMI          1      50                          
INDEX FULL SCAN     SCHEMA_B_LIVE.PK_CHANGEHISTORY     1      40                          
INDEX RANGE SCAN     SCHEMA_B_LIVE.IDX_LDR_CGHIST_TOID     1      10                          
as appose to the previous plan:
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
DELETE STATEMENT Optimizer Mode=ALL_ROWS 1 2.50067886958788
DELETE SCHEMA_B_LIVE.CHANGE_HISTORY
HASH JOIN SEMI 1 50 2.50067886958788
INDEX FULL SCAN SCHEMA_B_LIVE.PK_CHANGEHISTORY 1 40
TABLE ACCESS FULL SCHEMA_B_LIVE.LOADER_CHANGEHISTORY 1 10 2.00065584594569
Tony