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