Why are two queries better than one

Question

I'm trying to help out our developers who are struggling with the performance of a very simple select statmenent that for some reason is exhibiting some very inexplicable results.
I'll show the SQL as a single statement first.....
select * from transaction1 t where t.hid in (select distinct h.hid from history1 h,filter1 f where h.fid = f.fid and f.match='value');
transaction 1 has 250k records, history1 has about 100k as does filter1. We know generally the subselect will only return a total of half a dozen or less records (only 1 in our testing here).
Running the above query takes around 7 seconds.
Changing this to a with clause.....
WITH a as (select distinct h.hid from history1 h,filter1 f where h.fid = f.fid and f.match='value') select * from transaction1 t where t,hid in (select a.hid from a);
and the runtime drops to 3 seconds. But then re-running the first statement again also now takes 3 seconds (so I guess there's some caching going on there).
Now what really puzzles is if we split this into two queries.....
select distinct h.hid from history1 h,filter1 f where h.fid = f.fid and f.match='value';
This takes .1 of a second,
select * from transaction1 t where t.hid in (12345);
And this takes .1 of a second.
So why when run seperately are they so fast, yet combined they take so long. I'm a bit baffled by this. We've rewritten the same SQL in half a dozen different ways with the same result and also done the same thing with other tables as well. Is it an optimisation issue?

Answer 1

Appologies for not following protocol, my first time posting on here.
Oracle 10g clustered.
We have limited access as it's a customers server, but the explain plan comes back as....
PLAN_TABLE_OUTPUT
Plan hash value: 898894568
| Id  | Operation            | Name              | Rows  | Bytes | Cost (%CPU)|Time     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT     |                   | 49553 |    37M|  7075   (2)|00:01:25 |
|*  1 |  HASH JOIN RIGHT SEMI|                   | 49553 |    37M|  7075   (2)|00:01:25 |
|   2 |   VIEW               | VW_NSO_1          | 26131 |   331K|   476   (4)|00:00:06 |
|*  3 |    HASH JOIN         |                   | 26131 |   791K|   476   (4)|00:00:06 |
PLAN_TABLE_OUTPUT
|*  4 |     TABLE ACCESS FULL| FILTER1           | 26131 |   484K|   246   (4)|00:00:03 |
|   5 |     TABLE ACCESS FULL| HISTORY1          |   104K|  1225K|   227   (3)|00:00:03 |
|   6 |   TABLE ACCESS FULL  | TRANSACTION1      |   199K|   150M|  6593   (1)|00:01:20 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   1 - access("T"."TID"="$nso_col_1")
   3 - access("H"."HID"="F"."ID")
   4 - filter("F"."MATCH"='value')
20 rows selectedI'll admit, I'm not completely clear on what I'm reading here, other than the fact there are some big differences in the timing values
We don't have privaleges to run trace, so I'm a bit stuffed there as I'm on the clients site, however I will get my developers to try this on our local server.
Edited by: user1410957 on 15-Sep-2009 06:14