Home Explore Blog CI



postgresql

91th chunk of `doc/src/sgml/monitoring.sgml`
f9e96cb53a696de3376835628079799891db631f98c34ef20000000100000bc4
 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>

Title: Using Queries to Display Table, TOAST, and Index Sizes; Handling Disk Full Failures
Summary
This section provides SQL queries to display the space used by tables, TOAST tables, and indexes in PostgreSQL. It also discusses the importance of monitoring disk space to prevent 'disk full' failures, which can halt database activity or cause a server panic if WAL files are affected. Tablespaces can be used to move database files to other file systems if disk space is limited. It is important to monitor disk usage before it is completely full, and to consider any user-specific disk quotas that may apply.