<quote>autovacuum launcher</quote> process will not
   be present if you have set the system not to run autovacuum.)
   Each of the remaining
   processes is a server process handling one client connection.  Each such
   process sets its command line display in the form

<screen>
postgres: <replaceable>user</replaceable> <replaceable>database</replaceable> <replaceable>host</replaceable> <replaceable>activity</replaceable>
</screen>

  The user, database, and (client) host items remain the same for
  the life of the client connection, but the activity indicator changes.
  The activity can be <literal>idle</literal> (i.e., waiting for a client command),
  <literal>idle in transaction</literal> (waiting for client inside a <command>BEGIN</command> block),
  or a command type name such as <literal>SELECT</literal>.  Also,
  <literal>waiting</literal> is appended if the server process is presently waiting
  on a lock held by another session.  In the above example we can infer
  that process 15606 is waiting for process 15610 to complete its transaction
  and thereby release some lock.  (Process 15610 must be the blocker, because
  there is no other active session.  In more complicated cases it would be
  necessary to look into the
  <link linkend="view-pg-locks"><structname>pg_locks</structname></link>
  system view to determine who is blocking whom.)
  </para>

  <para>
   If <xref linkend="guc-cluster-name"/> has been configured the
   cluster name will also be shown in <command>ps</command> output:
<screen>
$ psql -c 'SHOW cluster_name'
 cluster_name
--------------
 server1
(1 row)

$ ps aux|grep server1
postgres   27093  0.0  0.0  30096  2752 ?        Ss   11:34   0:00 postgres: server1: background writer
...
</screen>
  </para>

  <para>
   If you have turned off <xref linkend="guc-update-process-title"/> then the
   activity indicator is not updated; the process title is set only once
   when a new process is launched.  On some platforms this saves a measurable
   amount of per-command overhead;  on others it's insignificant.
  </para>

  <tip>
  <para>
  <productname>Solaris</productname> requires special handling. You must
  use <command>/usr/ucb/ps</command>, rather than
  <command>/bin/ps</command>. You also must use two <option>w</option>
  flags, not just one. In addition, your original invocation of the
  <command>postgres</command> command must have a shorter
  <command>ps</command> status display than that provided by each
  server process.  If you fail to do all three things, the <command>ps</command>
  output for each server process will be the original <command>postgres</command>
  command line.
  </para>
  </tip>
 </sect1>

 <sect1 id="monitoring-stats">
  <title>The Cumulative Statistics System</title>

  <indexterm zone="monitoring-stats">
   <primary>statistics</primary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname>'s <firstterm>cumulative statistics
   system</firstterm> supports collection and reporting of information about
   server activity.  Presently, accesses to tables and indexes in both
   disk-block and individual-row terms are counted.  The total number of rows
   in each table, and information about vacuum and analyze actions for each
   table are also counted.  If enabled, calls to user-defined functions and
   the total time spent in each one are counted as well.
  </para>

  <para>
   <productname>PostgreSQL</productname> also supports reporting dynamic
   information about exactly what is going on in the system right now, such as
   the exact command currently being executed by other server processes, and
   which other connections exist in the system.  This facility is independent
   of the cumulative statistics system.
  </para>

 <sect2 id="monitoring-stats-setup">
  <title>Statistics Collection Configuration</title>

  <para>
   Since collection of statistics adds some overhead to query execution,
   the system can be configured to collect or not collect information.