Re: Performance of MERGE INTO statement
- From: "조동욱" <ukja.dion@xxxxxxxxx>
- To: JHostetter@xxxxxxxxxxxxxxxxxxxx
- Date: Mon, 19 May 2008 08:49:41 +0900
>
> Finn - I'm not sure why the optimizer thinks that there is only one row.
> I've gathered stats and the NUM_ROWS column shows 3,041,890. There are
> presently two partitions on this table. USER_TAB_PARTITIONS shows that
> one has 1,078 rows and the other has 4,089,540 rows (it's partitioned by
> month and I've been testing it with one month of data).
>
> * | 20 | TABLE ACCESS FULL | CALL_FACTS | 1 | 66
> | 1358 | KEY | KEY |
>
You did not post the predicate information. (where call_facts.c1 = ... )
Oracle applied some basic formulars for your predicate and the result was
"1"(or 0).
Predicate part of the execution plan is essential when interpreting the
cardinality and cost.
Dion Cho
- References:
- Re: Performance of MERGE INTO statement
- From: Finn Jorgensen
- RE: Performance of MERGE INTO statement
- From: Hostetter, Jay M
Other related posts:
- » Performance of MERGE INTO statement
- » Re: Performance of MERGE INTO statement
- » Re: Performance of MERGE INTO statement
- » RE: Performance of MERGE INTO statement
- » RE: Performance of MERGE INTO statement
- » RE: Performance of MERGE INTO statement
- » Re: Performance of MERGE INTO statement
- » Re: Performance of MERGE INTO statement
- Re: Performance of MERGE INTO statement
- From: Finn Jorgensen
- RE: Performance of MERGE INTO statement
- From: Hostetter, Jay M