monitoring.sgml 29.4 KB
Newer Older
1
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.35 2006/06/27 19:07:50 momjian Exp $ -->
2 3 4 5

<chapter id="monitoring">
 <title>Monitoring Database Activity</title>

Peter Eisentraut's avatar
Peter Eisentraut committed
6 7 8 9 10 11 12 13 14 15
 <indexterm zone="monitoring">
  <primary>monitoring</primary>
  <secondary>database activity</secondary>
 </indexterm>

 <indexterm zone="monitoring">
  <primary>database activity</primary>
  <secondary>monitoring</secondary>
 </indexterm>

16
 <para>
17
  A database administrator frequently wonders, <quote>What is the system
18 19 20 21 22 23 24
  doing right now?</quote>
  This chapter discusses how to find that out.
 </para>

  <para>
   Several tools are available for monitoring database activity and
   analyzing performance.  Most of this chapter is devoted to describing
25
   <productname>PostgreSQL</productname>'s statistics collector,
26
   but one should not neglect regular Unix monitoring programs such as
27 28
   <command>ps</>, <command>top</>, <command>iostat</>, and <command>vmstat</>.
   Also, once one has identified a
29
   poorly-performing query, further investigation may be needed using
30 31
   <productname>PostgreSQL</productname>'s <xref linkend="sql-explain"
   endterm="sql-explain-title"> command.
32
   <xref linkend="using-explain"> discusses <command>EXPLAIN</>
33 34 35 36 37 38 39
   and other methods for understanding the behavior of an individual
   query.
  </para>

 <sect1 id="monitoring-ps">
  <title>Standard Unix Tools</Title>

40 41 42 43 44
  <indexterm zone="monitoring-ps">
   <primary>ps</primary>
   <secondary>to monitor activity</secondary>
  </indexterm>

45 46 47 48 49 50 51
  <para>
   On most platforms, <productname>PostgreSQL</productname> modifies its
   command title as reported by <command>ps</>, so that individual server
   processes can readily be identified.  A sample display is

<screen>
$ ps auxww | grep ^postgres
52
postgres   960  0.0  1.1  6104 1480 pts/1    SN   13:17   0:00 postgres -i
53 54
postgres   963  0.0  1.1  7084 1472 pts/1    SN   13:17   0:00 postgres: stats buffer process   
postgres   965  0.0  1.1  6152 1512 pts/1    SN   13:17   0:00 postgres: stats collector process   
Tom Lane's avatar
Typo.  
Tom Lane committed
55
postgres   998  0.0  2.3  6532 2992 pts/1    SN   13:18   0:00 postgres: tgl runbug 127.0.0.1 idle
56 57 58 59 60 61 62
postgres  1003  0.0  2.4  6532 3128 pts/1    SN   13:19   0:00 postgres: tgl regression [local] SELECT waiting
postgres  1016  0.1  2.4  6532 3080 pts/1    SN   13:19   0:00 postgres: tgl regression [local] idle in transaction
</screen>

   (The appropriate invocation of <command>ps</> varies across different
   platforms, as do the details of what is shown.  This example is from a
   recent Linux system.)  The first process listed here is the
63
   the master server process.  The command arguments
64 65 66 67 68 69 70 71
   shown for it are the same ones given when it was launched.  The next two
   processes implement the statistics collector, which will be described in
   detail in the next section.  (These will not be present if you have set
   the system not to start the statistics collector.)  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>
Tom Lane's avatar
Typo.  
Tom Lane committed
72
postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <replaceable>activity</>
73 74 75 76
</screen>

  The user, database, and connection source host items remain the same for
  the life of the client connection, but the activity indicator changes.
77 78
  The activity may be <literal>idle</> (i.e., waiting for a client command),
  <literal>idle in transaction</> (waiting for client inside a <command>BEGIN</> block),
79
  or a command type name such as <literal>SELECT</>.  Also,
80
  <literal>waiting</> is attached if the server process is presently waiting
81 82 83 84
  on a lock held by another server process.  In the above example we can infer
  that process 1003 is waiting for process 1016 to complete its transaction and
  thereby release some lock or other.
  </para>
85 86 87 88 89

  <tip>
  <para>
  <productname>Solaris</productname> requires special handling. You must
  use <command>/usr/ucb/ps</command>, rather than
90
  <command>/bin/ps</command>. You also must use two <option>w</option>
91
  flags, not just one. In addition, your original invocation of the
92
  <command>postgres</command> command must have a shorter
93
  <command>ps</command> status display than that provided by each
94
  server process.  If you fail to do all three things, the <command>ps</>
95
  output for each server process will be the original <command>postgres</>
Bruce Momjian's avatar
Bruce Momjian committed
96
  command line.
97 98
  </para>
  </tip>
99 100 101
 </sect1>

 <sect1 id="monitoring-stats">
102
  <title>The Statistics Collector</Title>
103

104 105 106 107
  <indexterm zone="monitoring-stats">
   <primary>statistics</primary>
  </indexterm>

108 109 110 111
  <para>
   <productname>PostgreSQL</productname>'s <firstterm>statistics collector</>
   is a subsystem that supports collection and reporting of information about
   server activity.  Presently, the collector can count accesses to tables
112 113 114 115 116 117 118 119
   and indexes in both disk-block and individual-row terms.
  </para>

  <para>
   <productname>PostgreSQL</productname> also supports determining the exact
   command currently being executed by other server processes.  This is an
   independent facility that can be enabled or disabled whether or not
   block-level and row-level statistics are being collected.
120 121 122 123 124 125 126 127
  </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.
128 129 130
   This is controlled by configuration parameters that are normally set in
   <filename>postgresql.conf</>.  (See <xref linkend="runtime-config"> for
   details about setting configuration parameters.)
131 132 133
  </para>

  <para>
134 135 136 137 138 139 140
   The parameter <xref linkend="guc-stats-start-collector"> must be
   set to <literal>true</> for the statistics collector to be launched
   at all.  This is the default and recommended setting, but it may be
   turned off if you have no interest in statistics and want to
   squeeze out every last drop of overhead.  (The savings is likely to
   be small, however.)  Note that this option cannot be changed while
   the server is running.
141 142 143
  </para>

  <para>
144
   The parameters <xref linkend="guc-stats-block-level"> and <xref
145
   linkend="guc-stats-row-level"> control how much information is
146
   actually sent to the collector and thus determine how much run-time
147
   overhead occurs.  These respectively determine whether a server
148 149
   process tracks disk-block-level access
   statistics and row-level access statistics and sends these to the collector.
150
   Additionally, per-database transaction commit and abort statistics
151 152 153 154 155 156 157 158
   are collected if either of these parameters are set.
  </para>

  <para>
   The parameter <xref linkend="guc-stats-command-string"> enables monitoring
   of the current command being executed by any server process.
   The statistics collector subprocess need not be running to enable this
   feature.
159 160 161 162 163 164 165
  </para>
  
  <para>
   Normally these parameters are set in <filename>postgresql.conf</> so
   that they apply to all server processes, but it is possible to turn
   them on or off in individual sessions using the <xref
   linkend="sql-set" endterm="sql-set-title"> command. (To prevent
166 167 168
   ordinary users from hiding their activity from the administrator,
   only superusers are allowed to change these parameters with
   <command>SET</>.)
169 170
  </para>

171
   <note>
172
    <para>
173
     Since the parameters <varname>stats_block_level</varname>, and
174
     <varname>stats_row_level</varname> default to <literal>false</>,
175
     very few statistics are collected in the default
176 177
     configuration. Enabling either of these configuration
     variables will significantly increase the amount of useful data
178
     produced by the statistics facilities, at the expense of
179
     additional run-time overhead.
180
    </para>
181
   </note>
182 183 184 185 186 187 188

 </sect2>

 <sect2 id="monitoring-stats-views">
  <title>Viewing Collected Statistics</Title>

  <para>
189 190 191
   Several predefined views, listed in <xref
   linkend="monitoring-stats-views-table">, are available to show the results
   of statistics collection.  Alternatively, one can
192
   build custom views using the underlying statistics functions.
193 194 195 196 197
  </para>

  <para>
   When using the statistics to monitor current activity, it is important
   to realize that the information does not update instantaneously.
198 199
   Each individual server process transmits new block and row access counts to
   the collector just before going idle; so a query or transaction still in
200
   progress does not affect the displayed totals.  Also, the collector itself
201 202
   emits a new report at most once per <varname>PGSTAT_STAT_INTERVAL</varname>
   milliseconds (500 unless altered while building the server).  So the
203 204 205
   displayed information lags behind actual activity.  However, current-query
   information collected by <varname>stats_command_string</varname> is
   always up-to-date.
206 207 208 209
  </para>

  <para>
   Another important point is that when a server process is asked to display
210
   any of these statistics, it first fetches the most recent report emitted by
211
   the collector process and then continues to use this snapshot for all
212 213
   statistical views and functions until the end of its current transaction.
   So the statistics will appear not to change as long as you continue the
214 215 216 217
   current transaction.  Similarly, information about the current queries of
   all processes is collected when any such information is first requested
   within a transaction, and the same information will be displayed throughout
   the transaction.
218 219 220 221 222 223 224
   This is a feature, not a bug, because it allows you to perform several
   queries on the statistics and correlate the results without worrying that
   the numbers are changing underneath you.  But if you want to see new
   results with each query, be sure to do the queries outside any transaction
   block.
  </para>

225
  <table id="monitoring-stats-views-table">
226 227 228 229 230 231 232 233 234 235 236 237 238
   <title>Standard Statistics Views</title>

   <tgroup cols="2">
    <thead>
     <row>
      <entry>View Name</entry>
      <entry>Description</entry>
     </row>
    </thead>

    <tbody>
     <row>
      <entry><structname>pg_stat_activity</></entry>
239 240 241 242
      <entry>One row per server process, showing database OID, database name,
      process <acronym>ID</>, user OID, user name, current query, time at
      which the current query began execution, time at which the process
      was started, and client's address and port number.  The columns
243
      that report data on the current query are available unless the
244
      parameter <varname>stats_command_string</varname> has been
245
      turned off.  Furthermore, these columns are only visible if the
246
      user examining the view is a superuser or the same as the user
247 248
      owning the process being reported on.
     </entry>
249 250 251 252
     </row>

     <row>
      <entry><structname>pg_stat_database</></entry>
253 254 255 256
      <entry>One row per database, showing database OID, database name,
      number of active server processes connected to that database,
      number of transactions committed and rolled back in that database,
      total disk blocks read, and total buffer hits (i.e., block
257 258 259 260 261 262
      read requests avoided by finding the block already in buffer cache).
     </entry>
     </row>

     <row>
      <entry><structname>pg_stat_all_tables</></entry>
263
      <entry>For each table in the current database (including TOAST tables),
264 265 266
      the table OID, schema and table name, the last time the table was
      vacuumed by the user and the autovacuum daemon, the last time the table
      was analyzed by the user and the autovacuum daemon, number of sequential
267 268 269 270 271
      scans initiated, number of live rows fetched by sequential
      scans, number of index scans initiated (over all indexes
      belonging to the table), number of live rows fetched by index
      scans,
      and numbers of row insertions, updates, and deletions.</entry>
272 273 274 275
     </row>

     <row>
      <entry><structname>pg_stat_sys_tables</></entry>
276 277
      <entry>Same as <structname>pg_stat_all_tables</>, except that only
      system tables are shown.</entry>
278 279 280 281
     </row>

     <row>
      <entry><structname>pg_stat_user_tables</></entry>
282 283
      <entry>Same as <structname>pg_stat_all_tables</>, except that only user
      tables are shown.</entry>
284 285 286 287
     </row>

     <row>
      <entry><structname>pg_stat_all_indexes</></entry>
288 289 290 291 292
      <entry>For each index in the current database,
      the table and index OID, schema, table and index name,
      number of index scans initiated on that index, number of
      index entries returned by index scans, and number of live table rows
      fetched by simple index scans using that index.
293 294 295 296 297
      </entry>
     </row>

     <row>
      <entry><structname>pg_stat_sys_indexes</></entry>
298 299
      <entry>Same as <structname>pg_stat_all_indexes</>, except that only
      indexes on system tables are shown.</entry>
300 301 302 303
     </row>

     <row>
      <entry><structname>pg_stat_user_indexes</></entry>
304 305
      <entry>Same as <structname>pg_stat_all_indexes</>, except that only
      indexes on user tables are shown.</entry>
306 307 308 309
     </row>

     <row>
      <entry><structname>pg_statio_all_tables</></entry>
310 311 312 313 314 315
      <entry>For each table in the current database (including TOAST tables),
      the table OID, schema and table name, number of disk
      blocks read from that table, number of buffer hits, numbers of
      disk blocks read and buffer hits in all indexes of that table,
      numbers of disk blocks read and buffer hits from that table's
      auxiliary TOAST table (if any), and numbers of disk blocks read
316 317 318 319 320 321
      and buffer hits for the TOAST table's index.
      </entry>
     </row>

     <row>
      <entry><structname>pg_statio_sys_tables</></entry>
322 323
      <entry>Same as <structname>pg_statio_all_tables</>, except that only
      system tables are shown.</entry>
324 325 326 327
     </row>

     <row>
      <entry><structname>pg_statio_user_tables</></entry>
328 329
      <entry>Same as <structname>pg_statio_all_tables</>, except that only
      user tables are shown.</entry>
330 331 332 333
     </row>

     <row>
      <entry><structname>pg_statio_all_indexes</></entry>
334 335 336
      <entry>For each index in the current database,
      the table and index OID, schema, table and index name,
      numbers of disk blocks read and buffer hits in that index.
337 338 339 340 341
      </entry>
     </row>

     <row>
      <entry><structname>pg_statio_sys_indexes</></entry>
342 343
      <entry>Same as <structname>pg_statio_all_indexes</>, except that only
      indexes on system tables are shown.</entry>
344 345 346 347
     </row>

     <row>
      <entry><structname>pg_statio_user_indexes</></entry>
348 349
      <entry>Same as <structname>pg_statio_all_indexes</>, except that only
      indexes on user tables are shown.</entry>
350 351 352 353
     </row>

     <row>
      <entry><structname>pg_statio_all_sequences</></entry>
354 355 356
      <entry>For each sequence object in the current database,
      the sequence OID, schema and sequence name,
      numbers of disk blocks read and buffer hits in that sequence.
357 358 359 360 361
      </entry>
     </row>

     <row>
      <entry><structname>pg_statio_sys_sequences</></entry>
362 363
      <entry>Same as <structname>pg_statio_all_sequences</>, except that only
      system sequences are shown.  (Presently, no system sequences are defined,
364 365 366 367 368
      so this view is always empty.)</entry>
     </row>

     <row>
      <entry><structname>pg_statio_user_sequences</></entry>
369 370
      <entry>Same as <structname>pg_statio_all_sequences</>, except that only
      user sequences are shown.</entry>
371 372 373 374 375 376 377 378 379 380
     </row>
    </tbody>
   </tgroup>
  </table>

  <para>
   The per-index statistics are particularly useful to determine which
   indexes are being used and how effective they are.
  </para>

381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406
  <para>
   Beginning in <productname>PostgreSQL</productname> 8.1, indexes can be
   used either directly or via <quote>bitmap scans</>.  In a bitmap scan
   the output of several indexes can be combined via AND or OR rules;
   so it is difficult to associate individual heap row fetches 
   with specific indexes when a bitmap scan is used.  Therefore, a bitmap
   scan increments the
   <structname>pg_stat_all_indexes</>.<structfield>idx_tup_read</>
   count(s) for the index(es) it uses, and it increments the
   <structname>pg_stat_all_tables</>.<structfield>idx_tup_fetch</>
   count for the table, but it does not affect
   <structname>pg_stat_all_indexes</>.<structfield>idx_tup_fetch</>.
  </para>

  <note>
   <para>
    Before <productname>PostgreSQL</productname> 8.1, the
    <structfield>idx_tup_read</> and <structfield>idx_tup_fetch</> counts
    were essentially always equal.  Now they can be different even without
    considering bitmap scans, because <structfield>idx_tup_read</> counts
    index entries retrieved from the index while <structfield>idx_tup_fetch</>
    counts live rows fetched from the table; the latter will be less if any
    dead or not-yet-committed rows are fetched using the index.
   </para>
  </note>

407
  <para>
408 409 410 411 412 413 414 415 416 417 418 419 420 421
   The <structname>pg_statio_</> views are primarily useful to
   determine the effectiveness of the buffer cache.  When the number
   of actual disk reads is much smaller than the number of buffer
   hits, then the cache is satisfying most read requests without
   invoking a kernel call. However, these statistics do not give the
   entire story: due to the way in which <productname>PostgreSQL</>
   handles disk I/O, data that is not in the
   <productname>PostgreSQL</> buffer cache may still reside in the
   kernel's I/O cache, and may therefore still be fetched without
   requiring a physical read. Users interested in obtaining more
   detailed information on <productname>PostgreSQL</> I/O behavior are
   advised to use the <productname>PostgreSQL</> statistics collector
   in combination with operating system utilities that allow insight
   into the kernel's handling of I/O.
422 423 424
  </para>

  <para>
425 426 427 428
   Other ways of looking at the statistics can be set up by writing
   queries that use the same underlying statistics access functions as
   these standard views do.  These functions are listed in <xref
   linkend="monitoring-stats-funcs-table">.  The per-database access
Peter Eisentraut's avatar
Peter Eisentraut committed
429 430 431 432
   functions take a database OID as argument to identify which
   database to report on.  The per-table and per-index functions take
   a table or index OID.  (Note that only tables and indexes in the
   current database can be seen with these functions.)  The
433
   per-server-process access functions take a server process
Peter Eisentraut's avatar
Peter Eisentraut committed
434
   number, which ranges from one to the number of currently active
435
   server processes.
436 437
  </para>

438
  <table id="monitoring-stats-funcs-table">
439 440 441 442 443 444 445 446 447 448 449 450 451
   <title>Statistics Access Functions</title>

   <tgroup cols="3">
    <thead>
     <row>
      <entry>Function</entry>
      <entry>Return Type</entry>
      <entry>Description</entry>
     </row>
    </thead>

    <tbody>
     <row>
452
      <entry><literal><function>pg_stat_get_db_numbackends</function>(<type>oid</type>)</literal></entry>
453 454
      <entry><type>integer</type></entry>
      <entry>
455
       Number of active server processes for database
456 457 458 459
      </entry>
     </row>

     <row>
460
      <entry><literal><function>pg_stat_get_db_xact_commit</function>(<type>oid</type>)</literal></entry>
461 462 463 464 465 466 467
      <entry><type>bigint</type></entry>
      <entry>
       Transactions committed in database
      </entry>
     </row>

     <row>
468
      <entry><literal><function>pg_stat_get_db_xact_rollback</function>(<type>oid</type>)</literal></entry>
469 470 471 472 473 474 475
      <entry><type>bigint</type></entry>
      <entry>
       Transactions rolled back in database
      </entry>
     </row>

     <row>
476
      <entry><literal><function>pg_stat_get_db_blocks_fetched</function>(<type>oid</type>)</literal></entry>
477 478 479 480 481 482 483
      <entry><type>bigint</type></entry>
      <entry>
       Number of disk block fetch requests for database
      </entry>
     </row>

     <row>
484
      <entry><literal><function>pg_stat_get_db_blocks_hit</function>(<type>oid</type>)</literal></entry>
485 486
      <entry><type>bigint</type></entry>
      <entry>
487
       Number of disk block fetch requests found in cache for database
488 489 490 491
      </entry>
     </row>

     <row>
492
      <entry><literal><function>pg_stat_get_numscans</function>(<type>oid</type>)</literal></entry>
493 494 495 496 497 498 499 500
      <entry><type>bigint</type></entry>
      <entry>
       Number of sequential scans done when argument is a table,
       or number of index scans done when argument is an index
      </entry>
     </row>

     <row>
501
      <entry><literal><function>pg_stat_get_tuples_returned</function>(<type>oid</type>)</literal></entry>
502 503
      <entry><type>bigint</type></entry>
      <entry>
504
       Number of rows read by sequential scans when argument is a table,
505
       or number of index entries returned when argument is an index
506 507 508 509
      </entry>
     </row>

     <row>
510
      <entry><literal><function>pg_stat_get_tuples_fetched</function>(<type>oid</type>)</literal></entry>
511 512
      <entry><type>bigint</type></entry>
      <entry>
513 514
       Number of table rows fetched by bitmap scans when argument is a table,
       or table rows fetched by simple index scans using the index
515 516 517 518 519
       when argument is an index
      </entry>
     </row>

     <row>
520
      <entry><literal><function>pg_stat_get_tuples_inserted</function>(<type>oid</type>)</literal></entry>
521 522
      <entry><type>bigint</type></entry>
      <entry>
523
       Number of rows inserted into table
524 525 526 527
      </entry>
     </row>

     <row>
528
      <entry><literal><function>pg_stat_get_tuples_updated</function>(<type>oid</type>)</literal></entry>
529 530
      <entry><type>bigint</type></entry>
      <entry>
531
       Number of rows updated in table
532 533 534 535
      </entry>
     </row>

     <row>
536
      <entry><literal><function>pg_stat_get_tuples_deleted</function>(<type>oid</type>)</literal></entry>
537 538
      <entry><type>bigint</type></entry>
      <entry>
539
       Number of rows deleted from table
540 541 542 543
      </entry>
     </row>

     <row>
544
      <entry><literal><function>pg_stat_get_blocks_fetched</function>(<type>oid</type>)</literal></entry>
545 546 547 548 549 550 551
      <entry><type>bigint</type></entry>
      <entry>
       Number of disk block fetch requests for table or index
      </entry>
     </row>

     <row>
552
      <entry><literal><function>pg_stat_get_blocks_hit</function>(<type>oid</type>)</literal></entry>
553 554 555 556 557 558
      <entry><type>bigint</type></entry>
      <entry>
       Number of disk block requests found in cache for table or index
      </entry>
     </row>

559 560 561 562
     <row>
      <entry><literal><function>pg_stat_get_last_vacuum_time</function>(<type>oid</type>)</literal></entry>
      <entry><type>timestamptz</type></entry>
      <entry>
563
       Time of the last vacuum initiated by the user on this table
564 565 566 567 568 569 570
      </entry>
     </row>

     <row>
      <entry><literal><function>pg_stat_get_last_autovacuum_time</function>(<type>oid</type>)</literal></entry>
      <entry><type>timestamptz</type></entry>
      <entry>
571
       Time of the last vacuum initiated by the autovacuum daemon on this table
572 573 574 575 576 577 578
      </entry>
     </row>

     <row>
      <entry><literal><function>pg_stat_get_last_analyze_time</function>(<type>oid</type>)</literal></entry>
      <entry><type>timestamptz</type></entry>
      <entry>
579
       Time of the last analyze initiated by the user on this table
580 581 582 583 584 585 586
      </entry>
     </row>

     <row>
      <entry><literal><function>pg_stat_get_last_autoanalyze_time</function>(<type>oid</type>)</literal></entry>
      <entry><type>timestamptz</type></entry>
      <entry>
587 588
       Time of the last analyze initiated by the autovacuum daemon on this
       table
589 590 591
      </entry>
     </row>

592
     <row>
593
      <entry><literal><function>pg_stat_get_backend_idset</function>()</literal></entry>
594
      <entry><type>setof integer</type></entry>
595
      <entry>
596 597
       Set of currently active server process numbers (from 1 to the
       number of active server processes).  See usage example in the text
598 599
      </entry>
     </row>
600 601

     <row>
602
      <entry><literal><function>pg_backend_pid</function>()</literal></entry>
603 604
      <entry><type>integer</type></entry>
      <entry>
605
       Process ID of the server process attached to the current session
606 607
      </entry>
     </row>
608

609
     <row>
610
      <entry><literal><function>pg_stat_get_backend_pid</function>(<type>integer</type>)</literal></entry>
611 612
      <entry><type>integer</type></entry>
      <entry>
613
       Process ID of the given server process
614 615 616 617
      </entry>
     </row>

     <row>
618
      <entry><literal><function>pg_stat_get_backend_dbid</function>(<type>integer</type>)</literal></entry>
619 620
      <entry><type>oid</type></entry>
      <entry>
621
       Database ID of the given server process
622 623 624 625
      </entry>
     </row>

     <row>
626
      <entry><literal><function>pg_stat_get_backend_userid</function>(<type>integer</type>)</literal></entry>
627 628
      <entry><type>oid</type></entry>
      <entry>
629
       User ID of the given server process
630 631 632 633
      </entry>
     </row>

     <row>
634
      <entry><literal><function>pg_stat_get_backend_activity</function>(<type>integer</type>)</literal></entry>
635 636
      <entry><type>text</type></entry>
      <entry>
637 638 639 640
       Active command of the given server process, but only if the
       current user is a superuser or the same user as that of
       the session being queried (and
       <varname>stats_command_string</varname> is on)
641 642
      </entry>
     </row>
643

644
     <row>
645
      <entry><literal><function>pg_stat_get_backend_activity_start</function>(<type>integer</type>)</literal></entry>
646
      <entry><type>timestamp with time zone</type></entry>
647
      <entry>
648
       The time at which the given server process' currently
649 650 651 652
       executing query was started, but only if the
       current user is a superuser or the same user as that of
       the session being queried (and
       <varname>stats_command_string</varname> is on)
653 654 655
      </entry>
     </row>

656 657 658 659
     <row>
      <entry><literal><function>pg_stat_get_backend_start</function>(<type>integer</type>)</literal></entry>
      <entry><type>timestamp with time zone</type></entry>
      <entry>
660
       The time at which the given server process was started, or
661 662 663 664 665 666 667 668 669 670
       null if the current user is not a superuser nor the same user
       as that of the session being queried
      </entry>
     </row>

     <row>
      <entry><literal><function>pg_stat_get_backend_client_addr</function>(<type>integer</type>)</literal></entry>
      <entry><type>inet</type></entry>
      <entry>
       The IP address of the client connected to the given
671
       server process. Null if the connection is over a Unix domain
672 673 674 675 676 677 678 679 680 681
       socket. Also null if the current user is not a superuser nor
       the same user as that of the session being queried
      </entry>
     </row>

     <row>
      <entry><literal><function>pg_stat_get_backend_client_port</function>(<type>integer</type>)</literal></entry>
      <entry><type>integer</type></entry>
      <entry>
       The IP port number of the client connected to the given
682
       server process.  -1 if the connection is over a Unix domain
683 684 685 686 687
       socket. Null if the current user is not a superuser nor the
       same user as that of the session being queried
      </entry>
     </row>

688
     <row>
689
      <entry><literal><function>pg_stat_reset</function>()</literal></entry>
690 691
      <entry><type>boolean</type></entry>
      <entry>
692
       Reset all block-level and row-level statistics to zero
693 694
      </entry>
     </row>
695 696 697 698
    </tbody>
   </tgroup>
  </table>

699 700
   <note>
    <para>
701 702
     <function>blocks_fetched</function> minus
     <function>blocks_hit</function> gives the number of kernel
703 704 705 706 707
     <function>read()</> calls issued for the table, index, or
     database; but the actual number of physical reads is usually
     lower due to kernel-level buffering.
    </para>
   </note>
708 709 710

  <para>
   The function <function>pg_stat_get_backend_idset</function> provides
711 712
   a convenient way to generate one row for each active server process.  For
   example, to show the <acronym>PID</>s and current queries of all server processes:
713 714

<programlisting>
715 716 717
SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
       pg_stat_get_backend_activity(s.backendid) AS current_query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
718 719 720 721 722
</programlisting>
  </para>

 </sect2>
 </sect1>
723

724 725 726
 <sect1 id="monitoring-locks">
  <title>Viewing Locks</title>

Peter Eisentraut's avatar
Peter Eisentraut committed
727 728 729 730 731
  <indexterm zone="monitoring-locks">
   <primary>lock</primary>
   <secondary>monitoring</secondary>
  </indexterm>

732 733
  <para>
   Another useful tool for monitoring database activity is the
734
   <structname>pg_locks</structname> system table.  It allows the
735 736 737
   database administrator to view information about the outstanding
   locks in the lock manager. For example, this capability can be used
   to:
738

739 740 741 742 743 744 745 746 747 748 749 750
   <itemizedlist>
    <listitem>
     <para>
      View all the locks currently outstanding, all the locks on
      relations in a particular database, all the locks on a
      particular relation, or all the locks held by a particular
      <productname>PostgreSQL</productname> session.
     </para>
    </listitem>

    <listitem>
     <para>
751
      Determine the relation in the current database with the most
752 753 754 755 756 757 758 759 760 761 762 763 764 765
      ungranted locks (which might be a source of contention among
      database clients).
     </para>
    </listitem>

    <listitem>
     <para>
      Determine the effect of lock contention on overall database
      performance, as well as the extent to which contention varies
      with overall database traffic.
     </para>
    </listitem>
   </itemizedlist>

766 767
   Details of the <structname>pg_locks</structname> view appear in
   <xref linkend="view-pg-locks">.
768
   For more information on locking and managing concurrency with
769
   <productname>PostgreSQL</productname>, refer to <xref linkend="mvcc">.
770 771
  </para>
 </sect1>
772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789
</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->