svn commit - mysqldoc@docsrva: r4247 - in trunk: refman-5.0 refman-5.1

[jon]

Author: jstephens
Date: 2006-12-14 06:18:21 +0100 (Thu, 14 Dec 2006)
New Revision: 4247

Log:

Documenting fic for Cluster Bug #21507 (Bredbandsbolaget: UNIQUE + NULL)

(Thanks, Martin!)



Modified:
   trunk/refman-5.0/releasenotes-es-5.0.xml
   trunk/refman-5.1/news-5.1.xml


Modified: trunk/refman-5.0/releasenotes-es-5.0.xml
===================================================================
--- trunk/refman-5.0/releasenotes-es-5.0.xml	2006-12-14 05:02:30 UTC (rev 4246)
+++ trunk/refman-5.0/releasenotes-es-5.0.xml	2006-12-14 05:18:21 UTC (rev 4247)
Changed blocks: 1, Lines Added: 47, Lines Deleted: 0; 2399 bytes

@@ -56,6 +56,53 @@
     </para>
 
     <itemizedlist>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal>: It is now possible to create a
+          unique hashed index on a column that is not defined as
+          <literal>NOT NULL</literal>. <emphasis>Note that this change
+            applies only to tables using the <literal>NDB</literal>
+            storage engine</emphasis>.
+        </para>
+        
+        <para>
+          Unique indexes on columns in <literal>NDB</literal> tables do
+          not store null values because they are mapped to primary keys
+          in an internal index table (and primary keys cannot contain
+          nulls).
+        </para>
+        <para>
+          Normally, an additional ordered index is created when one
+          creates unique indexes on <literal>NDB</literal> table columns;
+          this can be used to search for <literal>NULL</literal> values.
+          However, if <literal>USING HASH</literal> is specified when
+          such an index is created, no ordered index is created.
+        </para>
+        
+        <para>
+          The reason for permitting unique hash indexes with null values
+          is that, in some cases, the user wants to save space if a
+          large number of records are pre-allocated but not fully
+          initialized. This also assumes that the user will
+          <emphasis>not</emphasis> try to search for null values. Since
+          MySQL does not support indexes that are not allowed to be
+          searched in some cases, the <literal>NDB</literal> storage
+          engine uses a full table scan with pushed conditions for the
+          referenced index columns to return the correct result. 
+        </para>
+        
+        <para>
+          Note that a warning is returned if one creates a unique
+          nullable hash index, since the query optimizer should be
+          provided a hint not to use it with <literal>NULL</literal>
+          values if this can be avoided.
+        </para>
+        
+        <para>
+          (Bug #21507)
+        </para>
+      </listitem>
 
       <listitem>
         <para>


Modified: trunk/refman-5.1/news-5.1.xml
===================================================================
--- trunk/refman-5.1/news-5.1.xml	2006-12-14 05:02:30 UTC (rev 4246)
+++ trunk/refman-5.1/news-5.1.xml	2006-12-14 05:18:21 UTC (rev 4247)
Changed blocks: 1, Lines Added: 47, Lines Deleted: 0; 2432 bytes

@@ -504,6 +504,53 @@
           <xref linkend="mysql-cluster-replication-schema"/>.
         </para>
       </listitem>
+      
+      <listitem>
+        <para>
+          <literal>NDB Cluster</literal>: It is now possible to create a
+          unique hashed index on a column that is not defined as
+          <literal>NOT NULL</literal>. <emphasis>Note that this change
+            applies only to tables using the <literal>NDB</literal>
+            storage engine</emphasis>.
+        </para>
+        
+        <para>
+          Unique indexes on columns in <literal>NDB</literal> tables do
+          not store null values because they are mapped to primary keys
+          in an internal index table (and primary keys cannot contain
+          nulls).
+        </para>
+        <para>
+          Normally, an additional ordered index is created when one
+          creates unique indexes on <literal>NDB</literal> table columns;
+          this can be used to search for <literal>NULL</literal> values.
+          However, if <literal>USING HASH</literal> is specified when
+          such an index is created, no ordered index is created.
+        </para>
+        
+        <para>
+          The reason for permitting unique hash indexes with null values
+          is that, in some cases, the user wants to save space if a
+          large number of records are pre-allocated but not fully
+          initialized. This also assumes that the user will
+          <emphasis>not</emphasis> try to search for null values. Since
+          MySQL does not support indexes that are not allowed to be
+          searched in some cases, the <literal>NDB</literal> storage
+          engine uses a full table scan with pushed conditions for the
+          referenced index columns to return the correct result. 
+        </para>
+        
+        <para>
+          Note that a warning is returned if one creates a unique
+          nullable hash index, since the query optimizer should be
+          provided a hint not to use it with <literal>NULL</literal>
+          values if this can be avoided.
+        </para>
+        
+        <para>
+          (Bug #21507)
+        </para>
+      </listitem>
 
       <listitem>
         <para>