Regarding explain plan

Question

hi all,
i am using database 10g.
i have explain as below
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 2715695103
| Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time
   |
|   0 | SELECT STATEMENT              |                        |     8 |   568 |     6  (17)| 00:00:
01 |
|   1 |  HASH UNIQUE                  |                        |     8 |   568 |     6  (17)| 00:00:
01 |
|   2 |   NESTED LOOPS                |                        |     8 |   568 |     5   (0)| 00:00:
01 |
|*  3 |    TABLE ACCESS FULL          | COMMON_PURCHASE_HEADER |     8 |   232 |     3   (0)| 00:00:
PLAN_TABLE_OUTPUT
01 |
|   4 |    TABLE ACCESS BY INDEX ROWID| CUSTOMER_MASTER        |     1 |    42 |     1   (0)| 00:00:
01 |
|*  5 |     INDEX UNIQUE SCAN         | CUM_PK                 |     1 |       |     0   (0)| 00:00:
01 |
----how we can analyse the query based on this plan.
Thanks..

Answer 1

What do you think an execution plan is? I think you think that this tells you all by itself how "good" the query is. No that's wrong. You can compare it with the advise a GPS system gives you to go from A to B. Some GPS system give better advices than others, some even know the current traffic situation. But, without any knowledge about the location you are in, you have to trust that plan.
But, if you live in that area, you might know that another path might me faster than the suggested one,etc.
All ORACLE tells you with this execution plan, is that it will read table COMMON_PURCHASE_HEADER completely and will join CUSTOMER_MASTER in a nested loop over the PK index.
WE do now know a lot about your DB, if there are other indexes (e.g. on C_STATUS) and what the cardinality on it is. If there would be an index, and the value A would just occur once, an INDEX lookup might be faster if you would have MUCH moire data!
On 8 rows....as the optimizer believes all data is on the same block and is read by 1 IO and that's the fastest access.
So, basically you need to learn what ORACLE tries to do.
Then you ask yourself, as you know the DB, if that's a clever idea.
If it's not, ask yourself why ORACLE does not agree with you. It might still be right. So test your access methods with hints, and you will see and learn.
As I said it's like the advice a GPS system gives you. Only a local can really tell you how clever that suggestion is. (And the local can be wrong) ;-)