<para>
   There are a few things to be careful about when adding trace macros
   to the C code:

   <itemizedlist>
    <listitem>
     <para>
      You should take care that the data types specified for a probe's
      parameters match the data types of the variables used in the macro.
      Otherwise, you will get compilation errors.
     </para>
    </listitem>


    <listitem>
     <para>
      On most platforms, if <productname>PostgreSQL</productname> is
      built with <option>--enable-dtrace</option>, the arguments to a trace
      macro will be evaluated whenever control passes through the
      macro, <emphasis>even if no tracing is being done</emphasis>.  This is
      usually not worth worrying about if you are just reporting the
      values of a few local variables.  But beware of putting expensive
      function calls into the arguments.  If you need to do that,
      consider protecting the macro with a check to see if the trace
      is actually enabled:

<programlisting>
if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
    TRACE_POSTGRESQL_TRANSACTION_START(some_function(...));
</programlisting>

      Each trace macro has a corresponding <literal>ENABLED</literal> macro.
     </para>
    </listitem>
   </itemizedlist>

  </para>

  </sect2>

 </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),