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

diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
index 6bec4e20b4a3c18a174bbc2ac87f13c8a394f205..3749c315ab9732322d2acdceb471d582273b9b4e 100644 (file)
--- a/doc/src/sgml/diskusage.sgml
+++ b/doc/src/sgml/diskusage.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -22,10 +22,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/diskusage.sgml,v 1.1 2002/06/13 05:15:22 mo
   
 
   
-   You can monitor disk space from two places; from inside
-   psql and from the command line using
-   contrib/oid2name. Using psql you can
-   issue queries to see the disk usage for any table:
+   You can monitor disk space from three places: from
+   psql using VACUUM information, from
+   psql using contrib/dbsize, and from
+   the command line using contrib/oid2name. Using
+   psql on a recently vacuumed (or analyzed) database,
+   you can issue queries to see the disk usage of any table:
 
 play=# SELECT relfilenode, relpages
 play-# FROM pg_class
@@ -38,10 +40,10 @@ play-# WHERE relname = 'customer';
   
 
      
-   Each page is typically 8 kilobytes. relpages is only
-   updated by VACUUM and ANALYZE. To show the
-   space used by TOAST tables, use a query based on the heap
-   relfilenode:
+   Each page is typically 8 kilobytes. (Remember, relpages
+   is only updated by VACUUM and ANALYZE.) To
+   show the space used by TOAST tables, use a query based on
+   the heap relfilenode shown above:
 
 play=# SELECT relname, relpages
 play-# FROM pg_class

diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml
index 214764a4a6c66b96b9c7f65221575c91fb3a5b67..b99832346f0759828bd93e09bfa37375fb049e3a 100644 (file)
--- a/doc/src/sgml/indices.sgml
+++ b/doc/src/sgml/indices.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Indexes
@@ -181,10 +181,11 @@ CREATE INDEX name ON table
 
    
     
-     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.
     
      
   

diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index 62963c21724d680aa2124c167c9d8c8990400c80..6821f6469147d02942bd324185d24c4eb08e25e9 100644 (file)
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -1,5 +1,5 @@
 
 
@@ -330,10 +330,11 @@ ERROR: Cannot create index: 'index_name' already exists.
     the = operator.
    
    
-     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.