Order By Clause - Slows performance

Question

On 10.2 when adding an order by clause to a query affects performance that returns 6 rows of data.
Before:
select distinct col1
from table1
Cost: 3,000
Execution Time: less than a second
Chooses: Bitmap Index Fast Full Scan Index (BitMap)
After:
select distinct col1
from table1
order by col1
Cost: 14,000
Execution time: 90 seconds
Chooses: Full TableScan
Any ideas as to why the order by causes the slow down ?
Thanks,

Answer 1

Venzi wrote:
Now you add the order by clause to it and Oracle has now to do a sort on it. It can't sort on the BITMAP index in that case so it has to go to the table. It is possible for Oracle to do the order by through the bitmap index - the reason it doesn't is probably down to arithmetic. (The situation is made a little messier by the fact that the table and index have been parallel enabled). Here's a plan from 10.2.0.3 showing the "order by" query running through the bitmap index:
| Id  | Operation                          | Name     | Rows  | Bytes | Cost  |    TQ  |IN-OUT| PQ Distrib |
|   0 | SELECT STATEMENT                   |          |     6 |    18 |   356 |        |      |            |
|   1 |  PX COORDINATOR                    |          |       |       |       |        |      |            |
|   2 |   PX SEND QC (ORDER)               | :TQ10001 |     6 |    18 |   356 |  Q1,01 | P->S | QC (ORDER) |
|   3 |    SORT GROUP BY                   |          |     6 |    18 |   356 |  Q1,01 | PCWP |            |
|   4 |     PX RECEIVE                     |          |  2000K|  5859K|    63 |  Q1,01 | PCWP |            |
|   5 |      PX SEND RANGE                 | :TQ10000 |  2000K|  5859K|    63 |  Q1,00 | P->P | RANGE      |
|   6 |       PX BLOCK ITERATOR            |          |  2000K|  5859K|    63 |  Q1,00 | PCWC |            |
|   7 |        BITMAP CONVERSION TO ROWIDS |          |  2000K|  5859K|    63 |  Q1,00 | PCWP |            |
|   8 |         BITMAP INDEX FAST FULL SCAN| T1_B1    |       |       |       |  Q1,00 | PCWP |            |
------------------------------------------------------------------------------------------------------------Note how the optimizer can recognise that the "group by" operation will allow it to avoid an explicit "order by" operation, and uses the "(ORDER)" distribution to pass the data to the Query Coordinator to enforce correct ordering.
Running up a test case with a couple of million rows, it looks like the underlying problem the OP has is that the CBO bypasses a few of the execution options in this particular case when parallel execution is possible. (I had to hint this plan - the default plan was a serial full scan of the index that allowed the optimizer to bypass the "sort order" because of a "sort unique", but the cost was much higher than this parallel plan - see below).
| Id  | Operation               | Name  | Rows  | Bytes | Cost  |
|   0 | SELECT STATEMENT        |       |     6 |    18 |  2269 |
|   1 |  SORT UNIQUE NOSORT     |       |     6 |    18 |  2269 |
|   2 |   BITMAP INDEX FULL SCAN| T1_B1 |  2000K|  5859K|   278 |
-----------------------------------------------------------------Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"I believe in evidence. I believe in observation, measurement, and reasoning, confirmed by independent observers. I'll believe anything, no matter how wild and ridiculous, if there is evidence for it. The wilder and more ridiculous something is, however, the firmer and more solid the evidence will have to be."+
Isaac Asimov