Question

Can anyone explain how the cost is evaluated in an Oracle explain plan?
Is there any specific algorithm to determine the cost of the query?

For example: full table scans have higher cost, index scan lower… How does Oracle evaluate the cases for full table scan, index range scan, etc.?

This link is same as what I am asking: Question about Cost in Oracle Explain Plan

But can anyone explain with an example, we can find the cost by executing explain plan, but how does it work internally?

Answer 1

There are many, many specific algorithms for computing the cost. Far more than could realistically be discussed here. Jonathan Lewis has done an admirable job of walking through how the cost-based optimizer decides on the cost of a query in his book Cost-Based Oracle Fundamentals. If you’re really interested, that’s going to to be the best place to start.

It is a fallacy to assume that full table scans will have a higher cost than, say, an index scan. It depends on the optimizer’s estimates of the number of rows in the table and the optimizer’s estimates of the number of rows the query will return (which, in turn, depends on the optimizer’s estimates of the selectivity of the various predicates), the relative cost of a sequential read vs. a serial read, the speed of the processor, the speed of the disk, the probability that blocks will be available in the buffer cache, your database’s optimizer settings, your session’s optimizer settings, the PARALLEL attribute of your tables and indexes, and a whole bunch of other factors (this is why it takes a book to really start to dive into this sort of thing). In general, Oracle will prefer a full table scan if your query is going to return a large fraction of the rows in your table and an index access if your query is going to return a small fraction of the rows in your table. And “small fraction” is generally much smaller than people initially estimate– if you’re returning 20-25% of the rows in a table, for example, you’re almost always better off using a full table scan.

If you are trying to use the COST column in a query plan to determine whether the plan is “good” or “bad”, you’re probably going down the wrong path. The COST is only valid if the optimizer’s estimates are accurate. But the most common reason that query plans would be incorrect is that the optimizer’s estimates are incorrect (statistics are incorrect, Oracle’s estimates of selectivity are incorrect, etc.). That means that if you see one plan for a query that has a cost of 6 and a plan for a different version of that query that has a cost of 6 million, it is entirely possible that the plan that has a cost of 6 million is more efficient because the plan with the low cost is incorrectly assuming that some step is going to return 1 row rather than 1 million rows.

You are much better served ignoring the COST column and focusing on the CARDINALITY column. CARDINALITY is the optimizer’s estimate of the number of rows that are going to be returned at each step of the plan. CARDINALITY is something you can directly test and compare against. If, for example, you see a step in the plan that involves a full scan of table A with no predicates and you know that A has roughly 100,000 rows, it would be concerning if the optimizer’s CARDINALITY estimate was either way too high or way too low. If it was estimating the cardinality to be 100 or 10,000,000 then the optimizer would almost certainly be either picking the table scan in error or feeding that data into a later step where its cost estimate would be grossly incorrect leading it to pick a poor join order or a poor join method. And it would probably indicate that the statistics on table A were incorrect. On the other hand, if you see that the cardinality estimates at each step is reasonably close to reality, there is a very good chance that Oracle has picked a reasonably good plan for the query.