Comments on: First_Rows

By: Jonathan Lewis

Jonathan Lewis — Tue, 15 Mar 2011 22:18:06 +0000

Johnwuwuwu, Thanks for that. Although the title suggests the fix is for the "proper" first_rows_K optimisation, the description suggests that the implementation would have made it apply to the old first_rows as a side-effect (pretty much as I surmised in my comment above.

By: johnwuwuwu

johnwuwuwu — Tue, 15 Mar 2011 08:47:54 +0000

It seems like hit Bug 7430474(FIRST_ROWS_K recost for ORDER BY elimination may not find best plan.)

By: Dom Brooks

Dom Brooks — Mon, 07 Mar 2011 14:18:13 +0000

I know we shouldn’t be using first_rows anyway but…

The 11.2.0.1 behaviour reported above by hourim is inconsistent with my 11.2.0.2 at least.

Running with 11.2.0.2, optimizer_features_enable=11.2.0.2 and optimizer_mode=first_rows, my 10053 trace showed only T1_BA as considered in the recost.

Having said that, although I thought I was initially able to reproduce the 11.2.0.1 change by way of optimizer_features_enable & optimizer_mode, I now think I must have been careless because subsequent attempts failed.

By: Jonathan Lewis

Jonathan Lewis — Sun, 06 Mar 2011 20:05:36 +0000

The trace file shows us that the logic has changed in 11.2. It’s then an interesting philosophical question whether the code for first_rows analysis has been modified (which seems unlikely if it exists for backwards compatibility only) or whether there is a structure to the optimisation strategy that has changed – thus removing a few possible paths from consideration – and it’s the arithmetic that changes within the boundaries of that structure. (I’d guess the latter.)

It might be possible to construct a complete answer by doing several more experiments using a larger collection of indexes on longer lists of columns – but that’s not a project I’d want to pursue at present.

By: hourim

hourim — Sun, 06 Mar 2011 07:35:51 +0000

Dear Jonathan, I generated the 10053 trace file and, if I have not missed anything, I can say that there is no recost for order by(using index) when I ordered by a,b and there is a recost for order by(using index) when I ordered by b but this recost doesn't change the original best access path. This is the 10053 trace file when I ordered by a, b [sourcecode language="sql"] optimizer_features_enable = 11.2.0.1 optimizer_mode = first_rows Access path analysis for T1 *************************************** SINGLE TABLE ACCESS PATH Single Table Cardinality Estimation for T1[T1] Table: T1 Alias: T1 Card: Original: 100000.000000 Rounded: 307 Computed: 307.44 Non Adjusted: 307.44 Access Path: TableScan Cost: 506.27 Resp: 506.27 Degree: 0 Cost_io: 503.00 Cost_cpu: 35196627 Resp_io: 503.00 Resp_cpu: 35196627 kkofmx: index filter:"T1"."A"='20110401' Access Path: index (skip-scan) SS sel: 0.003074 ANDV (#skips): 308.000000 SS io: 308.000000 vs. index scan io: 503.000000 Skip Scan chosen Access Path: index (SkipScan) Index: T1_BA resc_io: 617.00 resc_cpu: 23882848 ix_sel: 0.003074 ix_sel_with_filters: 0.003074 Cost: 619.22 Resp: 619.22 Degree: 1 Access Path: index (RangeScan) Index: T1_PK resc_io: 10.00 resc_cpu: 191334 ix_sel: 0.003074 ix_sel_with_filters: 0.003074 Cost: 10.02 Resp: 10.02 Degree: 1 ****** trying bitmap/domain indexes ****** ****** finished trying bitmap/domain indexes ****** Best:: AccessPath: IndexRange Index: T1_PK Cost: 10.02 Degree: 1 Resp: 10.02 Card: 307.44 Bytes: 0 *************************************** [/sourcecode] And this is the 10053 trace file when I ordered by b only [sourcecode language="sql"] optimizer_features_enable = 11.2.0.1 optimizer_mode = first_rows Access path analysis for T1 *************************************** SINGLE TABLE ACCESS PATH Single Table Cardinality Estimation for T1[T1] Table: T1 Alias: T1 Card: Original: 100000.000000 Rounded: 307 Computed: 307.44 Non Adjusted: 307.44 Access Path: TableScan Cost: 506.27 Resp: 506.27 Degree: 0 Cost_io: 503.00 Cost_cpu: 35196627 Resp_io: 503.00 Resp_cpu: 35196627 kkofmx: index filter:"T1"."A"='20110401' Access Path: index (skip-scan) SS sel: 0.003074 ANDV (#skips): 308.000000 SS io: 308.000000 vs. index scan io: 503.000000 Skip Scan chosen Access Path: index (SkipScan) Index: T1_BA resc_io: 617.00 resc_cpu: 23882848 ix_sel: 0.003074 ix_sel_with_filters: 0.003074 Cost: 619.22 Resp: 619.22 Degree: 1 Access Path: index (RangeScan) Index: T1_PK resc_io: 10.00 resc_cpu: 191334 ix_sel: 0.003074 ix_sel_with_filters: 0.003074 Cost: 10.02 Resp: 10.02 Degree: 1 ****** trying bitmap/domain indexes ****** ****** finished trying bitmap/domain indexes ****** Best:: AccessPath: IndexRange Index: T1_PK Cost: 10.02 Degree: 1 Resp: 10.02 Card: 307.44 Bytes: 0 ****** Recost for ORDER BY (using index) ************ Access path analysis for T1 *************************************** SINGLE TABLE ACCESS PATH Single Table Cardinality Estimation for T1[T1] Table: T1 Alias: T1 Card: Original: 100000.000000 Rounded: 307 Computed: 307.44 Non Adjusted: 307.44 Access Path: TableScan Cost: 506.27 Resp: 506.27 Degree: 0 Cost_io: 503.00 Cost_cpu: 35196627 Resp_io: 503.00 Resp_cpu: 35196627 Access Path: index (RangeScan) Index: T1_PK resc_io: 10.00 resc_cpu: 191334 ix_sel: 0.003074 ix_sel_with_filters: 0.003074 Cost: 10.02 Resp: 10.02 Degree: 1 Best:: AccessPath: IndexRange Index: T1_PK Cost: 10.02 Degree: 1 Resp: 10.02 Card: 307.44 Bytes: 24 [/sourcecode] Best Regards

By: Jonathan Lewis

Jonathan Lewis — Sat, 05 Mar 2011 08:57:24 +0000

Since you’re running 11.2.0.1 the first guess would be that Oracle has recognised a bug in earlier versions and fixed it – have you checked the release notes to see if there is anything about “bad choice of index under first_rows” ?

Although optimizer_features_enable will make the optimizer revert to earlier behaviour, I don’t think there’s any guarantee that it will re-introduce bugs that were present in earlier versions.

In your case I’d look at the 10053 trace to see if my comment about the “recost” is still true:

The most significant difference was the choice of indexes examined when the optimizer was doing the “recost for order by” bit. When we ordered by a,b the optimizer considered only the t1_ba index

By: hourim

hourim — Sat, 05 Mar 2011 08:47:31 +0000

Sorry Jonathan, Is it possible to let me know why I have the following observations? Thanks in advance [sourcecode gutter="false"] SQL> select * from v$version 2 where rownum=1; BANNER ----------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production SQL> alter session set optimizer_features_enable='10.2.0.3'; Session modifiée. SQL> select index_name, table_name 2 from user_indexes 3 where table_name='T1'; INDEX_NAME TABLE_NAME ------------------------------ T1_PK T1 T1_BA T1 SQL> alter session set optimizer_mode = first_rows; Session modifiée. SQL> select 2 small_vc 3 from 4 t1 5 where 6 a = '20110401' 7 and b > 10 8 order by 9 a, b 10 ; 307 ligne(s) sélectionnée(s). SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------------- SQL_ID bdfa9jku43jfh,child number 2 ------------------------------------- select small_vc from t1 where a = '20110401' and b > 10 order by a,b Plan hash value: 3756972603 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 11 (100)| | | 1 | SORT ORDER BY | | 307 | 7368 | 11 (10)| 00:00:01 | | 2 | TABLE ACCESS BY INDEX ROWID| T1 | 307 | 7368 | 10 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN | T1_PK | 307 | | 2 (0)| 00:00:01 | -------------------------------------------------------------------------------------- Predicate Information(identified by operationid): --------------------------------------------------- 3 - access("A"='20110401' AND "B">10) SQL> select 2 /*+ index(t1(a,b)) */ 3 small_vc 4 from 5 t1 6 where 7 a = '20110401' 8 and b > 10 9 order by 10 a, b 11 ; 307 ligne(s) sélectionnée(s). SQL> select * from table(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------- SQL_ID 20ppz5r9gk99q, child number 2 ------------------------------------- select /*+ index(t1(a,b)) */ small_vc from t1 where a ='20110401' and b > 10 order by a,b Plan hash value: 3756972603 -------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 11 (100)| | | 1 | SORT ORDER BY | | 307 | 7368 | 11 (10)| 00:00:01 | | 2 | TABLE ACCESS BY INDEX ROWID| T1 | 307 | 7368 | 10 (0)| 00:00:01 | |* 3 | INDEX RANGE SCAN | T1_PK | 307 | | 2 (0)| 00:00:01 | -------------------------------------------------------------------------------------- Predicate Information(identified by operationid): --------------------------------------------------- 3 - access("A"='20110401' AND "B">10) [/sourcecode]

By: Jonathan Lewis

Jonathan Lewis — Thu, 03 Mar 2011 17:53:01 +0000

Dom.
I’d forgotten all about that thread. It’s a pity that it died after I made the suggestion to rename the index. It would have been nice to have confirmation that it (probably) didn’t have an effect.

Looking at it again, I do wonder if the first_rows algorithm recosts all index-driven paths that bypass the “order by” – but, in this (these) cases, “knows” that the current best path is index-driven and therefore doesn’t include it in the recosting, then forgets to cross-check its cost against the ones it has recosted. It would be a fairly simple logic (or even counting) error to make this mistake.

By: Dom Brooks

Dom Brooks — Thu, 03 Mar 2011 12:20:31 +0000

> The first thought you might have when looking at this example is the first_rows has a heuristic
Indeed. I did.

On a similar case on OTN a while back, http://forums.oracle.com/forums/message.jspa?messageID=3231089#3231089 ,there was also a suggestion that the naming of the index might make a difference – i.e. first in alphabetical order. I did a quick test similar to above and it didn’t seem to.

By: Timur Akhmadeev

Timur Akhmadeev — Thu, 03 Mar 2011 09:48:21 +0000

Oracle doesn’t create a new index (a,b) because it can protect the primary key with the existing non-unique index (b,a).

Yep, this is it. I completely forgot about such thing.