docs: Demote "Monitoring Disk Usage" from chapter to section.

This chapter is very short, and the immediately preceding chapter is
called "Monitoring Database Activity". So, instead of having a
separate chapter for this, make it the last section of the preceding
chapter instead.

Discussion: http://postgr.es/m/CA+Tgmob7_uoYuS2=rVwpVXaRwP-UXz+++saYTC-BCZ42QzSNKQ@mail.gmail.com

diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
deleted file mode 100644 (file)
index 7546758..0000000
--- a/doc/src/sgml/diskusage.sgml
+++ /dev/null
@@ -1,144 +0,0 @@
-<!-- doc/src/sgml/diskusage.sgml -->
-
-<chapter id="diskusage">
- <title>Monitoring Disk Usage</title>
-
- <para>
-  This chapter discusses how to monitor the disk usage of a
-  <productname>PostgreSQL</productname> database system.
- </para>
-
- <sect1 id="disk-usage">
-  <title>Determining Disk Usage</title>
-
-  <indexterm zone="disk-usage">
-   <primary>disk usage</primary>
-  </indexterm>
-
-  <para>
-   Each table has a primary heap disk file where most of the data is
-   stored. If the table has any columns with potentially-wide values,
-   there also might be a <acronym>TOAST</acronym> file associated with the table,
-   which is used to store values too wide to fit comfortably in the main
-   table (see <xref linkend="storage-toast"/>).  There will be one valid index
-   on the <acronym>TOAST</acronym> table, if present. There also might be indexes
-   associated with the base table.  Each table and index is stored in a
-   separate disk file &mdash; possibly more than one file, if the file would
-   exceed one gigabyte.  Naming conventions for these files are described
-   in <xref linkend="storage-file-layout"/>.
-  </para>
-
-  <para>
-   You can monitor disk space in three ways:
-   using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
-   using the <xref linkend="oid2name"/> module, or
-   using manual inspection of the system catalogs.
-   The SQL functions are the easiest to use and are generally recommended.
-   The remainder of this section shows how to do it by inspection of the
-   system catalogs.
-  </para>
-
-  <para>
-   Using <application>psql</application> on a recently vacuumed or analyzed database,
-   you can issue queries to see the disk usage of any table:
-<programlisting>
-SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
-
- pg_relation_filepath | relpages
-----------------------+----------
- base/16384/16806     |       60
-(1 row)
-</programlisting>
-   Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
-   is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
-   a few DDL commands such as <command>CREATE INDEX</command>.)  The file path name
-   is of interest if you want to examine the table's disk file directly.
-  </para>
-
-  <para>
-   To show the space used by <acronym>TOAST</acronym> tables, use a query
-   like the following:
-<programlisting>
-SELECT relname, relpages
-FROM pg_class,
-     (SELECT reltoastrelid
-      FROM pg_class
-      WHERE relname = 'customer') AS ss
-WHERE oid = ss.reltoastrelid OR
-      oid = (SELECT indexrelid
-             FROM pg_index
-             WHERE indrelid = ss.reltoastrelid)
-ORDER BY relname;
-
-       relname        | relpages
-----------------------+----------
- pg_toast_16806       |        0
- pg_toast_16806_index |        1
-</programlisting>
-  </para>
-
-  <para>
-   You can easily display index sizes, too:
-<programlisting>
-SELECT c2.relname, c2.relpages
-FROM pg_class c, pg_class c2, pg_index i
-WHERE c.relname = 'customer' AND
-      c.oid = i.indrelid AND
-      c2.oid = i.indexrelid
-ORDER BY c2.relname;
-
-      relname      | relpages
--------------------+----------
- customer_id_index |       26
-</programlisting>
-  </para>
-
-  <para>
-   It is easy to find your largest tables and indexes using this
-   information:
-<programlisting>
-SELECT relname, relpages
-FROM pg_class
-ORDER BY relpages DESC;
-
-       relname        | relpages
-----------------------+----------
- bigtable             |     3290
- customer             |     3144
-</programlisting>
-  </para>
- </sect1>
-
- <sect1 id="disk-full">
-  <title>Disk Full Failure</title>
-
-  <para>
-   The most important disk monitoring task of a database administrator
-   is to make sure the disk doesn't become full.  A filled data disk will
-   not result in data corruption, but it might prevent useful activity
-   from occurring. If the disk holding the WAL files grows full, database
-   server panic and consequent shutdown might occur.
-  </para>
-
-  <para>
-   If you cannot free up additional space on the disk by deleting
-   other things, you can move some of the database files to other file
-   systems by making use of tablespaces. See <xref
-   linkend="manage-ag-tablespaces"/> for more information about that.
-  </para>
-
-  <tip>
-   <para>
-    Some file systems perform badly when they are almost full, so do
-    not wait until the disk is completely full to take action.
-   </para>
-  </tip>
-
-  <para>
-   If your system supports per-user disk quotas, then the database
-   will naturally be subject to whatever quota is placed on the user
-   the server runs as.  Exceeding the quota will have the same bad
-   effects as running out of disk space entirely.
-  </para>
- </sect1>
-</chapter>

diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index c92a16c7ac724f828ee35e9f2ab854045bda73d1..6360707d9f698b61060980865d3208c29c2a6ea3 100644 (file)
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -34,7 +34,6 @@
 <!ENTITY backup        SYSTEM "backup.sgml">
 <!ENTITY charset       SYSTEM "charset.sgml">
 <!ENTITY client-auth   SYSTEM "client-auth.sgml">
-<!ENTITY diskusage     SYSTEM "diskusage.sgml">
 <!ENTITY high-availability      SYSTEM "high-availability.sgml">
 <!ENTITY installbin    SYSTEM "install-binaries.sgml">
 <!ENTITY installation  SYSTEM "installation.sgml">

diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 6a74e4a24df9fec8ee7cb3cd4f15bed74ad86936..e1e96ba7c45fef482e8e4522c83e95201703cc3f 100644 (file)
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -7282,4 +7282,147 @@ if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
 
  </sect1>
 
+ <sect1 id="diskusage">
+  <title>Monitoring Disk Usage</title>
+
+  <para>
+   This section discusses how to monitor the disk usage of a
+   <productname>PostgreSQL</productname> database system.
+  </para>
+
+  <sect2 id="disk-usage">
+   <title>Determining Disk Usage</title>
+
+   <indexterm zone="disk-usage">
+    <primary>disk usage</primary>
+   </indexterm>
+
+   <para>
+    Each table has a primary heap disk file where most of the data is
+    stored. If the table has any columns with potentially-wide values,
+    there also might be a <acronym>TOAST</acronym> file associated with the table,
+    which is used to store values too wide to fit comfortably in the main
+    table (see <xref linkend="storage-toast"/>).  There will be one valid index
+    on the <acronym>TOAST</acronym> table, if present. There also might be indexes
+    associated with the base table.  Each table and index is stored in a
+    separate disk file &mdash; possibly more than one file, if the file would
+    exceed one gigabyte.  Naming conventions for these files are described
+    in <xref linkend="storage-file-layout"/>.
+   </para>
+
+   <para>
+    You can monitor disk space in three ways:
+    using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
+    using the <xref linkend="oid2name"/> module, or
+    using manual inspection of the system catalogs.
+    The SQL functions are the easiest to use and are generally recommended.
+    The remainder of this section shows how to do it by inspection of the
+    system catalogs.
+   </para>
+
+   <para>
+    Using <application>psql</application> on a recently vacuumed or analyzed
+    database, you can issue queries to see the disk usage of any table:
+<programlisting>
+SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
+
+ pg_relation_filepath | relpages
+----------------------+----------
+ base/16384/16806     |       60
+(1 row)
+</programlisting>
+    Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
+    is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
+    a few DDL commands such as <command>CREATE INDEX</command>.)  The file path name
+    is of interest if you want to examine the table's disk file directly.
+   </para>
+
+   <para>
+    To show the space used by <acronym>TOAST</acronym> tables, use a query
+    like the following:
+<programlisting>
+SELECT relname, relpages
+FROM pg_class,
+     (SELECT reltoastrelid
+      FROM pg_class
+      WHERE relname = 'customer') AS ss
+WHERE oid = ss.reltoastrelid OR
+      oid = (SELECT indexrelid
+             FROM pg_index
+             WHERE indrelid = ss.reltoastrelid)
+ORDER BY relname;
+
+       relname        | relpages
+----------------------+----------
+ pg_toast_16806       |        0
+ pg_toast_16806_index |        1
+</programlisting>
+   </para>
+
+   <para>
+    You can easily display index sizes, too:
+<programlisting>
+SELECT c2.relname, c2.relpages
+FROM pg_class c, pg_class c2, pg_index i
+WHERE c.relname = 'customer' AND
+      c.oid = i.indrelid AND
+      c2.oid = i.indexrelid
+ORDER BY c2.relname;
+
+      relname      | relpages
+-------------------+----------
+ customer_id_index |       26
+</programlisting>
+   </para>
+
+   <para>
+    It is easy to find your largest tables and indexes using this
+    information:
+<programlisting>
+SELECT relname, relpages
+FROM pg_class
+ORDER BY relpages DESC;
+
+       relname        | relpages
+----------------------+----------
+ bigtable             |     3290
+ customer             |     3144
+</programlisting>
+   </para>
+  </sect2>
+
+  <sect2 id="disk-full">
+   <title>Disk Full Failure</title>
+
+   <para>
+    The most important disk monitoring task of a database administrator
+    is to make sure the disk doesn't become full.  A filled data disk will
+    not result in data corruption, but it might prevent useful activity
+    from occurring. If the disk holding the WAL files grows full, database
+    server panic and consequent shutdown might occur.
+   </para>
+
+   <para>
+    If you cannot free up additional space on the disk by deleting
+    other things, you can move some of the database files to other file
+    systems by making use of tablespaces. See <xref
+    linkend="manage-ag-tablespaces"/> for more information about that.
+   </para>
+
+   <tip>
+    <para>
+     Some file systems perform badly when they are almost full, so do
+     not wait until the disk is completely full to take action.
+    </para>
+   </tip>
+
+   <para>
+    If your system supports per-user disk quotas, then the database
+    will naturally be subject to whatever quota is placed on the user
+    the server runs as.  Exceeding the quota will have the same bad
+    effects as running out of disk space entirely.
+   </para>
+  </sect2>
+ </sect1>
+
 </chapter>

diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 381af69be287395df23bbce16e59fd0abb2fdbc5..1ac9d3a9b8fff99329334dc8902e0f121f106b6a 100644 (file)
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -162,7 +162,6 @@ break is not needed in a wider output rendering.
   &backup;
   &high-availability;
   &monitoring;
-  &diskusage;
   &wal;
   &logical-replication;
   &jit;