2) The two plans are different – one of them counts key values, the other counts bits in the index entries (probably not really doing the conversion to rowids, but may it does). How different do you expect the plans to be ?

Thanks for your articles on BITMAP Indexes, they are very informational.

I have a question though,

example 1:
I am running simple distinct query on column which has bitmap index. table is non-partitioned. Theoretically, all distinct extries have an associated BITMAP so oracle has to just emit BITMAP headers. Then why is there a “HASH UNIQUE” step? Does this have anything to do with the fact that a BITMAP for a value is broken into multiple chunks.

example 2:
On same table, now I want to do “count(*)”. In this case also execution plan show same step “BITMAP INDEX FAST FULL SCAN”; I thought the operation is different in nature compared to previous distinct query. Earlier we were counting headers(example 1) so I was expecting to see some differentiation.

regards,

db version : DB 11Gr1, FX has ~4M rows; column c_id has 100 distinct values

select /*+ gather_plan_statistics */ distinct c_id from fx
Plan hash value: 693526871
—————————————————————————————————————————–
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem |
—————————————————————————————————————————–
| 1 | HASH UNIQUE | | 1 | 100 | 100 |00:00:00.01 | 731 | 1067K| 1067K| 1217K (0)|
| 2 | BITMAP INDEX FAST FULL SCAN| FX_BMP2 | 1 | 4163K| 1300 |00:00:00.01 | 731 | | | |
—————————————————————————————————————————–

example 2:
select /*+ gather_plan_statistics */ count(*) from fx
Plan hash value: 106145427
—————————————————————————————————
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
—————————————————————————————————
| 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:00.03 | 731 |
| 2 | BITMAP CONVERSION COUNT | | 1 | 4163K| 1300 |00:00:00.03 | 731 |
| 3 | BITMAP INDEX FAST FULL SCAN| FX_BMP2 | 1 | | 1300 |00:00:00.01 | 731 |
—————————————————————————————————

I believe the option for “temp_disabled” has nothing to do directly with memory usage; instead it changes the strategy used in the join back to the dimensions.

If the dimension tables are large and your query is known to identify a relatively small fraction of the rows from a dimension then Oracle has the option of extracting those rows from the dimension and copying them into a global temporary table (which is specially defined by in-memory metadata). This means that the join back will probably do a hash join with a small GTT, rather than joining back to a large dimension.

If you allow Oracle to use a GTT, then the memory usage ought to be blocks in the buffer cache, plus a PGA cost for buildling a hash table from the GTT.

If you opt for temp_disable, the join back could be a nested loop (on primary key), a merge join (which could result in two sorts, one large fact sort and a smaller dimension sort), or a hash join (which would probably build a hash table from the dimension table). Every query could be difference, and it could even be that the data set from the fact table is much smaller than the dimension anyway – which means the extracted fact data might be the thing that Oracle uses to build the hash table.

This doesn’t answer your question, but I hope it fills in some of the information around the edges.

We would like to use “star_transformation_enabled = temp_disabled” for our data warehouse implementation but are concerned about the amount of memory that could be used during the star transformation. We would like to measure the amount of memory used during our pre-production performance testing and
estimate the memory that could be used for our production user volume. Is the memory used when temp tables are disabled included in the session’s PGA usage?

Thanks,
Margaret

At least, in this case, the article mentions a version a couple of times, supplies the script for a test table, shows how to do block dumps, and reproduces a couple of extracts from a block dump to support the comments. Thus allowing people to discover, and demonstrate conclusively, that in 10g the indexes behave differently when faced with a string of single-row updates – although the same cannot be said about the undo and redo costs.

“regardless of it’s age”

Remember JL’s other rules including, “If it’s more than 6 weeks old it is rubbish and complete and utterly wrong.” Or something like that, can’t remember precisely.

@Ct

“I do point out them to my friends”

Not sure whether to feel pity or jealousy.

My best guess is that this refers to global indexes where there was pre-existing data in the partitions, and you were using the ‘maintain (global) indexes’ option, with the result that Oracle does a massive ‘direct path’ delete then insert on the indexes – which is exactly the type of operation where you are most likely to see waste space accumulating in the indexes.