Mention "PostgreSQL"'s hashes as slower/similar to btree.

diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
index 9353d1f8fcdbb05f04e5661f130726cebb669e88..ad8eb207cf83e60eec6e7c32e32e2b7c6cb90a13 100644 (file)
--- a/doc/src/sgml/diskusage.sgml
+++ b/doc/src/sgml/diskusage.sgml
@@ -22,10 +22,12 @@ $Header$
   </para>
 
   <para>
-   You can monitor disk space from two places; from inside
-   <application>psql</> and from the command line using
-   <application>contrib/oid2name</>. Using <application>psql</> you can
-   issue queries to see the disk usage for any table:
+   You can monitor disk space from three places: from
+   <application>psql</> using <command>VACUUM</> information, from
+   <application>psql</> using <application>contrib/dbsize</>, and from
+   the command line using <application>contrib/oid2name</>. Using
+   <application>psql</> on a recently vacuumed (or analyzed) database,
+   you can issue queries to see the disk usage of any table:
 <programlisting>
 play=# SELECT relfilenode, relpages
 play-# FROM pg_class
@@ -38,10 +40,10 @@ play-# WHERE relname = 'customer';
   </para>
 
   <para>   
-   Each page is typically 8 kilobytes. <literal>relpages</> is only
-   updated by <command>VACUUM</> and <command>ANALYZE</>. To show the
-   space used by <acronym>TOAST</> tables, use a query based on the heap
-   relfilenode:
+   Each page is typically 8 kilobytes. (Remember, <literal>relpages</>
+   is only updated by <command>VACUUM</> and <command>ANALYZE</>.) To
+   show the space used by <acronym>TOAST</> tables, use a query based on
+   the heap relfilenode shown above:
 <programlisting>
 play=# SELECT relname, relpages
 play-# FROM pg_class

diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml
index 7d605bb5c6e0b84e829a27653c64fcfc8fb06cee..a030714d23e76ee0925f106de67902ddeda59072 100644 (file)
--- a/doc/src/sgml/indices.sgml
+++ b/doc/src/sgml/indices.sgml
@@ -181,10 +181,11 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
 </synopsis>
    <note>
     <para>
-     Testing has shown hash indexes to be similar or slower than btree
-     indexes, and the index size and build time for hash indexes is much
-     worse. Hash indexes also suffer poor performance under high
-     concurrency. For these reasons, hash index use is discouraged.
+     Testing has shown PostgreSQL's hash indexes to be similar or slower
+     than btree indexes, and the index size and build time for hash
+     indexes is much worse. Hash indexes also suffer poor performance
+     under high concurrency. For these reasons, hash index use is
+     discouraged.
     </para>
    </note>  
   </para>

diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index 77334d0ed8686921ff215c47578e814e7079a9af..65b1b256de45873d18b2957e25b3f6622b82cd7c 100644 (file)
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -330,10 +330,11 @@ ERROR: Cannot create index: 'index_name' already exists.
     the <literal>=</literal> operator.
    </para>
    <para>
-     Testing has shown hash indexes to be similar or slower than btree
-     indexes, and the index size and build time for hash indexes is much
-     worse. Hash indexes also suffer poor performance under high
-     concurrency. For these reasons, hash index use is discouraged.
+     Testing has shown PostgreSQL's hash indexes to be similar or slower
+     than btree indexes, and the index size and build time for hash
+     indexes is much worse. Hash indexes also suffer poor performance
+     under high concurrency. For these reasons, hash index use is
+     discouraged.
    </para>
 
    <para>