Here's one, even though the cost on mine below beats yours, it still not close to yours with all the parallelism. SQL ID PLAN_HASH ID OPERATION COST 2cq1mddj3bd9r 2408568472 0 SELECT STATEMENT 639767482473649536 2cq1mddj3bd9r 2408568472 1 COUNT 2cq1mddj3bd9r 2408568472 2 FILTER 2cq1mddj3bd9r 2408568472 3 MERGE JOIN 639767482473649536 2cq1mddj3bd9r 2408568472 4 MERGE JOIN 494381333370 2cq1mddj3bd9r 2408568472 5 TABLE ACCESS 595409 2cq1mddj3bd9r 2408568472 6 BUFFER 494380737962 2cq1mddj3bd9r 2408568472 7 TABLE ACCESS 6583 2cq1mddj3bd9r 2408568472 8 BUFFER 639767482473643008 2cq1mddj3bd9r 2408568472 9 INDEX 3824 Maybe we have the same developers working on our systems...but hey - it must be the database :). Brent On Wed, Mar 27, 2013 at 2:44 PM, <DEEDSD@xxxxxxxxxxxxxx> wrote: > This was really neat. I had to look up what comes after 999 trillion to > figure out the cardinality, and what comes after 999 quadrillion to figure > out the cost (I added commas for clarity...) > SELECT STATEMENT Optimizer=ALL_ROWS (Cost=18,446,744,073,709,551,615) > PX COORDINATOR > PX SEND* (QC (ORDER)) OF :TQ10023 (Cost=18446744073709551615 > Cardinality=8180028 Bytes=924343164) > SORT* (ORDER BY) (Cost=18446744073709551615 Cardinality=8180028 > Bytes=924343164) > PX RECEIVE* (Cost=18446744073709551615 Cardinality=8180028 -- //www.freelists.org/webpage/oracle-l