From dad0e20f299bb674c7335a2cf15c47543210f69a Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Fri, 21 Jun 2002 19:06:44 +0000
Subject: [PATCH] Mention "PostgreSQL"'s hashes as slower/similar to btree.

---
 doc/src/sgml/diskusage.sgml        | 20 +++++++++++---------
 doc/src/sgml/indices.sgml          | 11 ++++++-----
 doc/src/sgml/ref/create_index.sgml | 11 ++++++-----
 3 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
index 6bec4e20b4..3749c315ab 100644
--- a/doc/src/sgml/diskusage.sgml
+++ b/doc/src/sgml/diskusage.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.1 2002/06/13 05:15:22 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.2 2002/06/21 19:06:44 momjian Exp $
 -->
 
 <chapter id="diskusage">
@@ -22,10 +22,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.1 2002/06/13 05:15:22 mo
   </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 214764a4a6..b99832346f 100644
--- a/doc/src/sgml/indices.sgml
+++ b/doc/src/sgml/indices.sgml
@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.33 2002/06/21 16:52:00 momjian Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.34 2002/06/21 19:06:44 momjian Exp $ -->
 
 <chapter id="indexes">
  <title id="indexes-title">Indexes</title>
@@ -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 62963c2172..6821f64691 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.33 2002/06/21 16:52:00 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.34 2002/06/21 19:06:44 momjian Exp $
 PostgreSQL documentation
 -->
 
@@ -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>
-- 
2.11.0