These figures are reused if a column is part of multiple indexes. The Oracle database maintains the information about the number of distinct column values as part of the table statistics. There are no dedicated operations or keywords for function-based indexes. The database traverses the B-tree and follows the leaf node chain. It is a regular INDEX RANGE SCAN as described in Chapter 1.
Index Cond: (upper((last_name)::text) = 'WINAND'::text) Recheck Cond: (upper((last_name)::text) = 'WINAND'::text) |*2 | INDEX RANGE SCAN | EMP_UP_NAME | 40 | 1 |Ģ - access(UPPER("LAST_NAME")='WINAND') PostgreSQL QUERY PLAN | 1 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 100 | 41 |
Mysql case select full#
See “ Full Table Scan” to see why that might make sense. This causes the optimizer to ignore the index and do a TBSCAN. When using UPPER('winand'), the optimizer does a gross misestimation and expects 4% of the table rows to be selected. The query was changed to WHERE UPPER(last_name) = 'WINAND' (no UPPER on the right hand side) to get the expected result. From the database’s perspective, that’s something entirely different.Ģ | FETCH EMPLOYEES | 1 of 1 (100.00%) | 13ģ | IXSCAN EMP_UP_NAME | 1 of 10000 (. Although there is an index on LAST_NAME, it is unusable-because the search is not on LAST_NAME but on UPPER(LAST_NAME). It is a return of our old friend the full table scan. Predicate Information (identified by operation id):ġ - filter(UPPER("LAST_NAME")='WINAND') PostgreSQL QUERY PLANįilter: (upper((last_name)::text) = 'WINAND'::text) |* 1 | TABLE ACCESS FULL| EMPLOYEES | 10 | 477 |
0 kommentar(er)
