If you mean that actual number of rows returned when you run the query (and this behavious is definitely happening when there’s no chance that someone else has been changing the data) then it’s a priority 1 bug (wrong results) and you should raise an SR.

If you mean the cardinality predicted in the execution plan changes then it’s also a bug – though less important one – possibly related to other features of the costing. You didn’t say which vesion you are using, and I have an example where the cardinality prediction changes between 11.1 and 11.2; the change doesn’t match your description, but it does show that a change is possible.

Thanks for the help..!!

I don’t know why the first appearance of the two temp tables shows the same name – but it’s probably just a little bug in the “explain plan” bit of the code.

It’s an interesting little oddity that when I run the query with star transformation in 11.1.0.6 and pull the plan from memory the “load as select” lines don’t hold a temporary table name at all.

That was a nice piece of reverse engineering, well done.

One extremely minor stuff: In the section where you explain the star transformation, second bullet point, you say “Lines 15-20 we do the same….” — That should probably read “Lines 16-20….” , right?

And one question: Why do the two temp tables generated for the PRODUCTS and CUSTOMERS tables share the same system generated name ( SYS_TEMP_0FD9D6601_17047D9 ) at the top part of the plan? The temp tables clearly have different names at the bottom of the plan.

Regards

thank you for the clarification – I should read more carefully …

Without cpu costing (/*+ opt_param(‘_optimizer_cost_model’,'io’) */) the cost for the FTS on products drop to 84, and when I recreate the table in another non-ASSM tablespace I get your value of 81 (I guess: because of the different HWM). Without cpu costing I also get the plan with two hash joins.

To get to the cost of 14 I had to set db_file_multiblock_read_count=128 – and that was a little surprise because the parameter had already this value (according to v$system_parameters); but then I remembered that there are hidden parameters to define different MBRC values for costing and for data access (_db_file_exec_read_count=128 and _db_file_optimizer_read_count=8). So I got my numbers sorted …

Your plan is covered by this comment: “discard a large fraction of those rows by indexing (or possibly doing a hash join) into the second dimension table”.

In passing, even though you’ve used my code to generate the data, there are still things like database parameters and system statistics (CPU Costing) that can vary; not to mention the possibility of stats gathering samples being different. You’ll notice, as an easy comparison, your line 9 shows a full tablescan of products at a cost of 209 with 2% CPU – my first example shows a cost of 14 without CPU (because I’d disable CPU costing). In fact when you get to my manually rewritten code you can see that I must triggered some change to my environment because the cost of the products tablescan in that plan is 81.

Thanks for the comment – I try to make a big thing about clarity in my presentations on writing efficient SQL, and I think that Oracle helps us make complex things appear simpler by allowing us to use inline views (or subquery factoring – although that sometimes causes undesirable side effects).

However most of us (or I) very rarely think of using three hints together.

I probably ought to admit, here, that I’ve actually not used enough hints – to my mind once you start putting in a “micro-management” hint like use_nl() you need to define the entire shape of the plan: so my three hints should have been five, because along with the no_merge hint I should have had:

join order for the query block – leading()
join method for every join – use_nl()
access method for every table – full(prd) index(ord (id_product))

I’ve written several notes about the diffculties of using hints well – in this case I should have been more strict with myself.

I just wanted to ask, how do we find whether star transformation is useful in such scenario or not ? Is there any way to identify whether bitmap conversions or index_joins are getting costlier ?

If the problem had been simple enough to answer in a comment to a blog it would be so simple that it would have been coded into the optimizer and you wouldn’t have needed to ask the question. If the optimizer can’t work it out you need to work it out for yourself, using your knowledge of the data to build a better model of the optimizer. See, for example, this article I wrote for Simple Talk.