<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Philosophy – 8</title>
	<atom:link href="http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/feed/" rel="self" type="application/rss+xml" />
	<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/</link>
	<description>Just another Oracle weblog</description>
	<lastBuildDate>Thu, 23 May 2013 12:47:17 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34785</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Tue, 03 Nov 2009 23:24:05 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34785</guid>
		<description><![CDATA[I agree; in fact, with the introduction of the btree/bitmap conversion mechanism a collection of single column b-tree indexes (which I once viewed as an indication of a design flaw) can be a very smart move to avoid creating a large number of multi-column indexes.

(The transformation and strategy is only available for enterprise edition, of course, &lt;a href=&quot;http://jonathanlewis.wordpress.com/2009/05/08/ioug-day-4/&quot; rel=&quot;nofollow&quot;&gt;&lt;em&gt;&lt;strong&gt;see this note&lt;/strong&gt;&lt;/em&gt;&lt;/a&gt;).]]></description>
		<content:encoded><![CDATA[<p>I agree; in fact, with the introduction of the btree/bitmap conversion mechanism a collection of single column b-tree indexes (which I once viewed as an indication of a design flaw) can be a very smart move to avoid creating a large number of multi-column indexes.</p>
<p>(The transformation and strategy is only available for enterprise edition, of course, <a href="http://jonathanlewis.wordpress.com/2009/05/08/ioug-day-4/" rel="nofollow"><em><strong>see this note</strong></em></a>).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34784</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Tue, 03 Nov 2009 23:18:40 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34784</guid>
		<description><![CDATA[I thought that the point I made in this note was fairly straightforward, but it has obviously caused some confusion - so I&#039;ll be writing another blog entry in a few days to expand on the concept given here.]]></description>
		<content:encoded><![CDATA[<p>I thought that the point I made in this note was fairly straightforward, but it has obviously caused some confusion &#8211; so I&#8217;ll be writing another blog entry in a few days to expand on the concept given here.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Howard Rogers</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34751</link>
		<dc:creator><![CDATA[Howard Rogers]]></dc:creator>
		<pubDate>Tue, 27 Oct 2009 12:01:50 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34751</guid>
		<description><![CDATA[I&#039;d like to just add into the mix that if you are thinking a bitmap index might be useful, but are put off by the fact you are multi-user-OLTP-ish, then think compressed b*tree indexes instead. For relatively low cardinality columns, a compressed b*tree index will be pretty small, just like a bitmap index will be. And you&#039;ll pay a CPU price for the compression (or rather, the decompression required to read the darn&#039;d thing). But you won&#039;t pay a thumping great big row locking issue. It may be a better bet is all I&#039;m saying.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;d like to just add into the mix that if you are thinking a bitmap index might be useful, but are put off by the fact you are multi-user-OLTP-ish, then think compressed b*tree indexes instead. For relatively low cardinality columns, a compressed b*tree index will be pretty small, just like a bitmap index will be. And you&#8217;ll pay a CPU price for the compression (or rather, the decompression required to read the darn&#8217;d thing). But you won&#8217;t pay a thumping great big row locking issue. It may be a better bet is all I&#8217;m saying.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Narendra</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34749</link>
		<dc:creator><![CDATA[Narendra]]></dc:creator>
		<pubDate>Tue, 27 Oct 2009 11:03:48 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34749</guid>
		<description><![CDATA[Mohamed,

Here is a scenario, that I experienced recently, where (I thought) bitmap indexes might have been useful in &lt;i&gt;&quot;multi-user OLTP&quot;&lt;/i&gt; application.
This system is used by many users and they do perform many small DMLs every day (hence qualifies the &quot;multi-user OLTP&quot; definition). However, this system has a set of tables, which act as base tables for a search algorithm (that is implemented using PL/SQL). These base tables are refreshed daily/weekly by a batch process. Many users concurrently perform searches (using the developed search algorithm) against these base tables (but only SELECTS and no INSERTs/UPDATEs/DELETEs). The search algorithm involves many queries that access few rows but on different combinations of columns in WHERE clause.
So, even though, the overall nature of this application is &quot;multi-user OLTP&quot;, this feature (search) in particular, acts like a &quot;DSS&quot; and can be benifited by having bitmap indexes on individual columns, instead of multiple composite B*Tree indexes, having same columns but in different order.]]></description>
		<content:encoded><![CDATA[<p>Mohamed,</p>
<p>Here is a scenario, that I experienced recently, where (I thought) bitmap indexes might have been useful in <i>&#8220;multi-user OLTP&#8221;</i> application.<br />
This system is used by many users and they do perform many small DMLs every day (hence qualifies the &#8220;multi-user OLTP&#8221; definition). However, this system has a set of tables, which act as base tables for a search algorithm (that is implemented using PL/SQL). These base tables are refreshed daily/weekly by a batch process. Many users concurrently perform searches (using the developed search algorithm) against these base tables (but only SELECTS and no INSERTs/UPDATEs/DELETEs). The search algorithm involves many queries that access few rows but on different combinations of columns in WHERE clause.<br />
So, even though, the overall nature of this application is &#8220;multi-user OLTP&#8221;, this feature (search) in particular, acts like a &#8220;DSS&#8221; and can be benifited by having bitmap indexes on individual columns, instead of multiple composite B*Tree indexes, having same columns but in different order.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bernard Polarski</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34745</link>
		<dc:creator><![CDATA[Bernard Polarski]]></dc:creator>
		<pubDate>Tue, 27 Oct 2009 10:10:48 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34745</guid>
		<description><![CDATA[After 15 years OLTPying, I may testify that what ever good intentions and super relational data model you possess, security procedure and logon trigger implemented, the very moment where you introduce a bitmap index into your OLTP, somebody, somewhere in a near or remote future, will manage to lock a row covered by this bitmap and your production will hang. Seems a Universal law.]]></description>
		<content:encoded><![CDATA[<p>After 15 years OLTPying, I may testify that what ever good intentions and super relational data model you possess, security procedure and logon trigger implemented, the very moment where you introduce a bitmap index into your OLTP, somebody, somewhere in a near or remote future, will manage to lock a row covered by this bitmap and your production will hang. Seems a Universal law.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Timur Akhmadeev</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34742</link>
		<dc:creator><![CDATA[Timur Akhmadeev]]></dc:creator>
		<pubDate>Tue, 27 Oct 2009 09:18:24 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34742</guid>
		<description><![CDATA[Joseph,

thank you. Your version sounds reasonable, but it doesn&#039;t fit to &quot;generic&quot; claim - there&#039;s no a word about is this multi-column indexes specific only or not. My first (and the only one) guess was something like this:
&lt;pre&gt;
drop table t cascade constraints purge;
create table t as 
select mod(rownum, 1e4) x, lpad(rownum, 10, &#039;0&#039;) pad from dba_objects, dba_objects 
 where rownum &lt;= 1e6;
create index t_indx on t(x);
exec dbms_stats.gather_table_stats(user, &#039;t&#039;, estimate_percent=&gt;null,method_opt=&gt;&#039;for all columns size 1&#039;);
select /*+ gather_plan_statistics */ * from t where x in (1, 2);
@x

drop index t_indx;
create bitmap index t_indx2_01 on t(decode(x, 1, x));
create bitmap index t_indx2_02 on t(decode(x, 2, x));
exec dbms_stats.gather_table_stats(user, &#039;t&#039;, estimate_percent=&gt;null,method_opt=&gt;&#039;for all hidden columns size 1&#039;)
select /*+ gather_plan_statistics */ * from t where decode(x, 1, x) = 1 or decode(x, 2, x) = 2;
@x
&lt;/pre&gt;
&lt;pre&gt;
-------------------------------------------------------------------------------------------------
&#124; Id  &#124; Operation                    &#124; Name   &#124; Starts &#124; E-Rows &#124; A-Rows &#124;   A-Time   &#124; Buffers &#124;
-------------------------------------------------------------------------------------------------
&#124;   1 &#124;  INLIST ITERATOR             &#124;        &#124;      1 &#124;        &#124;    200 &#124;00:00:00.01 &#124;     207 &#124;
&#124;   2 &#124;   TABLE ACCESS BY INDEX ROWID&#124; T      &#124;      2 &#124;    200 &#124;    200 &#124;00:00:00.01 &#124;     207 &#124;
&#124;*  3 &#124;    INDEX RANGE SCAN          &#124; T_INDX &#124;      2 &#124;    200 &#124;    200 &#124;00:00:00.01 &#124;       7 &#124;
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access((&quot;X&quot;=1 OR &quot;X&quot;=2))

-----------------------------------------------------------------------------------------------------
&#124; Id  &#124; Operation                    &#124; Name       &#124; Starts &#124; E-Rows &#124; A-Rows &#124;   A-Time   &#124; Buffers &#124;
-----------------------------------------------------------------------------------------------------
&#124;   1 &#124;  TABLE ACCESS BY INDEX ROWID &#124; T          &#124;      1 &#124;   1000K&#124;    200 &#124;00:00:00.01 &#124;     106 &#124;
&#124;   2 &#124;   BITMAP CONVERSION TO ROWIDS&#124;            &#124;      1 &#124;        &#124;    200 &#124;00:00:00.01 &#124;       4 &#124;
&#124;   3 &#124;    BITMAP OR                 &#124;            &#124;      1 &#124;        &#124;      1 &#124;00:00:00.01 &#124;       4 &#124;
&#124;*  4 &#124;     BITMAP INDEX SINGLE VALUE&#124; T_INDX2_01 &#124;      1 &#124;        &#124;      1 &#124;00:00:00.01 &#124;       2 &#124;
&#124;*  5 &#124;     BITMAP INDEX SINGLE VALUE&#124; T_INDX2_02 &#124;      1 &#124;        &#124;      1 &#124;00:00:00.01 &#124;       2 &#124;
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access(&quot;T&quot;.&quot;SYS_NC00003$&quot;=1)
   5 - access(&quot;T&quot;.&quot;SYS_NC00004$&quot;=2)
&lt;/pre&gt;]]></description>
		<content:encoded><![CDATA[<p>Joseph,</p>
<p>thank you. Your version sounds reasonable, but it doesn&#8217;t fit to &#8220;generic&#8221; claim &#8211; there&#8217;s no a word about is this multi-column indexes specific only or not. My first (and the only one) guess was something like this:</p>
<pre>
drop table t cascade constraints purge;
create table t as 
select mod(rownum, 1e4) x, lpad(rownum, 10, '0') pad from dba_objects, dba_objects 
 where rownum &lt;= 1e6;
create index t_indx on t(x);
exec dbms_stats.gather_table_stats(user, 't', estimate_percent=&gt;null,method_opt=&gt;'for all columns size 1');
select /*+ gather_plan_statistics */ * from t where x in (1, 2);
@x

drop index t_indx;
create bitmap index t_indx2_01 on t(decode(x, 1, x));
create bitmap index t_indx2_02 on t(decode(x, 2, x));
exec dbms_stats.gather_table_stats(user, 't', estimate_percent=&gt;null,method_opt=&gt;'for all hidden columns size 1')
select /*+ gather_plan_statistics */ * from t where decode(x, 1, x) = 1 or decode(x, 2, x) = 2;
@x
</pre>
<pre>
-------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------
|   1 |  INLIST ITERATOR             |        |      1 |        |    200 |00:00:00.01 |     207 |
|   2 |   TABLE ACCESS BY INDEX ROWID| T      |      2 |    200 |    200 |00:00:00.01 |     207 |
|*  3 |    INDEX RANGE SCAN          | T_INDX |      2 |    200 |    200 |00:00:00.01 |       7 |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access(("X"=1 OR "X"=2))

-----------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name       | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
-----------------------------------------------------------------------------------------------------
|   1 |  TABLE ACCESS BY INDEX ROWID | T          |      1 |   1000K|    200 |00:00:00.01 |     106 |
|   2 |   BITMAP CONVERSION TO ROWIDS|            |      1 |        |    200 |00:00:00.01 |       4 |
|   3 |    BITMAP OR                 |            |      1 |        |      1 |00:00:00.01 |       4 |
|*  4 |     BITMAP INDEX SINGLE VALUE| T_INDX2_01 |      1 |        |      1 |00:00:00.01 |       2 |
|*  5 |     BITMAP INDEX SINGLE VALUE| T_INDX2_02 |      1 |        |      1 |00:00:00.01 |       2 |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("T"."SYS_NC00003$"=1)
   5 - access("T"."SYS_NC00004$"=2)
</pre>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mohamed Houri</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34741</link>
		<dc:creator><![CDATA[Mohamed Houri]]></dc:creator>
		<pubDate>Tue, 27 Oct 2009 07:45:41 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34741</guid>
		<description><![CDATA[Hi jonathan,

It is very important that you included a Footenote to Philosophy8. I believe that before disussing the critical difference between B-tree indexes and Bitmap Indexes, we have first to discuss about the situations where itmap indexes are dangerous to implement.

In this context, I have one question,

Are there situations in  mutli-user OLTP applications where Bitmap indexes can be safely implemented so that one can start comparing their benefit versus  B-tree indexes benefit?

Mohamed Houri]]></description>
		<content:encoded><![CDATA[<p>Hi jonathan,</p>
<p>It is very important that you included a Footenote to Philosophy8. I believe that before disussing the critical difference between B-tree indexes and Bitmap Indexes, we have first to discuss about the situations where itmap indexes are dangerous to implement.</p>
<p>In this context, I have one question,</p>
<p>Are there situations in  mutli-user OLTP applications where Bitmap indexes can be safely implemented so that one can start comparing their benefit versus  B-tree indexes benefit?</p>
<p>Mohamed Houri</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joseph Charpak</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34734</link>
		<dc:creator><![CDATA[Joseph Charpak]]></dc:creator>
		<pubDate>Mon, 26 Oct 2009 22:14:14 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34734</guid>
		<description><![CDATA[What I think he&#039;s saying is that creating a bitmap index on something like &quot;gender&quot; (M/F) is not going to be too helpful if the data is split evenly between M and F. You still need to retrieve half the rows in the table. On the other hand, if you have additional columns with low cardinality e.g. &quot;hair color&quot;, &quot;eye color&quot;, etc. then it *might* make sense to build bitmap indexes on all three columns. Or not.

At least that&#039;s what I think he meant.]]></description>
		<content:encoded><![CDATA[<p>What I think he&#8217;s saying is that creating a bitmap index on something like &#8220;gender&#8221; (M/F) is not going to be too helpful if the data is split evenly between M and F. You still need to retrieve half the rows in the table. On the other hand, if you have additional columns with low cardinality e.g. &#8220;hair color&#8221;, &#8220;eye color&#8221;, etc. then it *might* make sense to build bitmap indexes on all three columns. Or not.</p>
<p>At least that&#8217;s what I think he meant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Timur Akhmadeev</title>
		<link>http://jonathanlewis.wordpress.com/2009/10/26/philosophy-8/#comment-34732</link>
		<dc:creator><![CDATA[Timur Akhmadeev]]></dc:creator>
		<pubDate>Mon, 26 Oct 2009 21:25:45 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/?p=2354#comment-34732</guid>
		<description><![CDATA[Jonathan,

Could you please clarify what do you mean by:
&gt;It is the combination of a subset of the available bitmap indexes that offers the same degree of precision.
I&#039;ve read it several times - and still don&#039;t get it.]]></description>
		<content:encoded><![CDATA[<p>Jonathan,</p>
<p>Could you please clarify what do you mean by:<br />
&gt;It is the combination of a subset of the available bitmap indexes that offers the same degree of precision.<br />
I&#8217;ve read it several times &#8211; and still don&#8217;t get it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
