Get a detailed, real-time view of your PostgreSQL database and system metrics
.. image:: https://travis-ci.org/zalando/pgview.svg?branch=master :target: https://travis-ci.org/zalando/pgview :alt: Build Status .. image:: https://img.shields.io/pypi/dw/pg-view.svg :target: https://pypi.python.org/pypi/pg-view :alt: PyPI Downloads .. image:: https://img.shields.io/pypi/l/pg-view.svg :target: https://pypi.python.org/pypi/pg-view :alt: License
pg_view is a powerful command-line tool that offers a detailed, real-time view of your PostgreSQL database and system metrics. It combines the indicators commonly displayed by sar or iostat with output from PostgreSQL's process activity view, and presents global and per-process statistics in an easy-to-interpret way.
pg_view shows these types of data:
pg_stat_activityview output for the backend and autovacuum processes
pgview can be especially helpful when you're monitoring system load, query locks and I/O utilization during lengthy data migrations. It's also useful when you're running servers 24x7 and aiming for zero downtime. Learn more about it at
.. contents:: :local: :depth: 1 :backlinks: none
To run pg_view, you'll need:
By default, pgview assumes that it can connect to a local PostgreSQL instance with the user postgres and no password. Some systems might require you to change your pghba.conf file or set the password in .pgpass. You can override the default user name with the -U command-line option or by setting the user key in the configuration file (see below).
pg_view queries system/process information files once per second. It also queries the filesystem to obtain postgres data directory and xlog usage statistics. Please note that the latter function might add an extra load to your disk subsystem.
.. image:: https://raw.github.com/zalando/pgview/master/images/pgviewscreenshotnew.png :alt: pg_view screenshot
By default, pg_view tries to autodetect all PostgreSQL clusters running on the same host by performing the following steps (in order):
If the program can't detect your connection arguments using the algorithm above, you can specify those arguments manually using the configuration file supplied with the -c option. This file should consist of one or more sections, each containing a key = value pair. You can also use your Connection Service File.
The title of each section represents a database cluster name (this name is for display purposes only). The dbname parameter is
postgresby default, and specifies the actual name of the database to connect to. The key-value pairs should contain connection parameters.
The valid keys are:
The special 'DEFAULT' section contains the parameters that apply for every database cluster if the corresponding parameter is missing from the database-specific section. For instance::
[testdb3] host=192.168.1.0 port=5433 dbname=test
Upon reading this file, the application will try using port 5435 (database postgres) to connect to both testdb and testdb2 clusters, and using the database name
testport 5433 to connect to testdb3.
If the auto-detection code works for you, you can select a single database by specifying the database instance name (in most cases, it will match the last component of $PGDATA) with the
-icommand-line option. If there is more than a single instance with the same name, you can additionally specify the required PG version with
You can get a short description of available configuration options with
pg_view supports three output methods:
Descriptions of some of the options:
out of memoryerrors, which will lead to a PostgreSQL shutdown.
Linux kernel documentation_.
/pg_xlog). This column is only shown during the warning (3h) or critical (1h) conditions, and only considers momentary writes. If a single process writes 100MB/s on a partition with 100GB left for only two seconds, it will show a critical status during those two seconds.
D- 'uninterruptable sleep'; see
man psfor more details.
fa second time to resume.
pg_view welcomes contributions; simply make a pull request.