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

doc/src/sgml/diskusage.sgml

 <!--
-$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

doc/src/sgml/indices.sgml

-<!-- $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>

doc/src/sgml/ref/create_index.sgml

 <!--
-$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>