## Who's online

There are currently 0 users and 23 guests online.

# CBO

## Temp Table Transformation Cardinality Estimates - 1

Having published recently two notes about the Temp Table Transformation highlighting the heuristics based decision and other weaknesses, for example regarding the projection of columns, it's time to publish some more notes about it.The transformation can also have significant impact on cardinality estimates, both join and single table cardinality.Looking at the difference in the join cardinality estimates of following simple example:

`create table t1asselect        rownum as id      , mod(rownum, 10) + 1 as id2      , rpad('x', 100) as fillerfrom        dualconnect by        level <= 1000;`

## Heuristic Temp Table Transformation - 2

Some time ago I've demonstrated the non-cost based decision for applying the temp table transformation when using CTEs (Common Table/Subquery Expressions). In this note I want to highlight another aspect of this behaviour.Consider the following data creating a table with delibrately wide columns:

`create table aas  select          rownum as id        , rownum as id2        , rpad('x', 4000) as large_vc1        , rpad('x', 4000) as large_vc2        , rpad('x', 4000) as large_vc3from          dualconnect by          level <= 1000;exec dbms_stats.gather_table_stats(null, 'a')`

## Function-Based Indexes And CURSOR_SHARING = FORCE

In general it is known that Function-Based Indexes (FBIs) can no longer be used by the optimizer if the expression contains literals and CURSOR_SHARING = FORCE / SIMILAR (deprecated) turns those literals into bind variables.

## Not Exists

The following requirement appeared recently on OTN:

## Combined ACCESS And FILTER Predicates - Excessive Throw-Away

Catchy title... Let's assume the following data setup:

`create table t1asselect        rownum as id      , 1 as id2      , rpad('x', 100) as fillerfrom        dualconnect by        level <= 1e4;create table t2asselect        rownum as id      , 1 as id2      , rpad('x', 100) as fillerfrom        dualconnect by        level <= 1e4;create table t3asselect        rownum as id      , 1 as id2      , rpad('x', 100) as fillerfrom        dualconnect by        level <= 1e4;exec dbms_stats.gather_table_stats(null, 't1')exec dbms_stats.gather_table_stats(null, 't2')exec dbms_stats.gather_table_stats(null, 't3')`

## push_pred – evolution

Here’s a query (with a few hints to control how I want Oracle to run it) that demonstrates the difficulty of trying to solve problems by hinting (and the need to make sure you know where all your hinted code is):

## Cardinality Change

Here’s an entertaining little change across versions of Oracle, brought to my attention by Tony Hasler during UKOUG Tech 14. It’s a join cardinality estimate, so here are a couple of tables to demonstrate the issue – the only columns needed are the alpha_06 columns, but I reused some code from other demonstrations to create my test case, so there are lots of irrelevant columns in the create table script:

## Closure

It’s been a long time since I said anything interesting about transitive closure in Oracle, the mechanism by which Oracle can infer that if a = b and b = c then a = c but only (in Oracle’s case) if one of a, b, or c is a literal constant rather than a column. So with that quick reminder in place, here’s an example of optimizer mechanics to worry you. It’s not actually a demonstration of transitive closure coming into play, but I wanted to remind you of the logic to set the scene.

I have a simple script that creates two identical tables , collects stats (with no histograms) on the pair of them, then executes a join. Here’s the SQL to create the first table:

## Lunchtime quiz

There was a question on OTN a few days ago asking the following question:

Here’s a query that ran okay on 11g, but crashed with Oracle error “ORA-01843: not a valid month” after upgrade to 12c; why ?

The generically correct answer, of course, is that the OP had been lucky (or unlucky, depending on your point of view) on 11g – and I’ll explain that answer in another blog posting.

That isn’t the point of this posting, though. This posting is a test of observation and deduction. One of the respondants in the thread had conveniently supplied a little bit of SQL that I copied and fiddled about with to demonstrate a point regarding CPU costing, but as I did so I thought I’d show you the following and ask a simple question.’