This chapter discusses how to monitor the disk usage of a PostgreSQL database system. disk usage 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 is also a TOAST file associated with the table, which is used to store values too wide to fit comfortably in the main table (see ). There will be one index on the TOAST table, if present. There may also be indexes associated with the base table. Each table and index is stored in a separate disk file — possibly more than one file, if the file would exceed one gigabyte. Naming conventions for these files are described in . You can monitor disk space from three ways: using SQL functions listed in , using VACUUM information, and from the command line using the tools in contrib/oid2name. The SQL functions are the easiest to use and report information about tables, tables with indexes and long value storage (TOAST), databases, and tablespaces. Using psql on a recently vacuumed or analyzed database, you can issue queries to see the disk usage of any table: SELECT relfilenode, relpages FROM pg_class WHERE relname = 'customer'; relfilenode | relpages -------------+---------- 16806 | 60 (1 row) Each page is typically 8 kilobytes. (Remember, relpages is only updated by VACUUM, ANALYZE, and a few DDL commands such as CREATE INDEX.) The relfilenode value is of interest if you want to examine the table's disk file directly. To show the space used by TOAST tables, use a query like the following: SELECT relname, relpages FROM pg_class, (SELECT reltoastrelid FROM pg_class WHERE relname = 'customer') ss WHERE oid = ss.reltoastrelid OR oid = (SELECT reltoastidxid FROM pg_class WHERE oid = ss.reltoastrelid) ORDER BY relname; relname | relpages ----------------------+---------- pg_toast_16806 | 0 pg_toast_16806_index | 1 You can easily display index sizes, too: 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_indexdex | 26 It is easy to find your largest tables and indexes using this information: SELECT relname, relpages FROM pg_class ORDER BY relpages DESC; relname | relpages ----------------------+---------- bigtable | 3290 customer | 3144 You can also use contrib/oid2name to show disk usage. See README.oid2name in that directory for examples. It includes a script that shows disk usage for each database. The most important disk monitoring task of a database administrator is to make sure the disk doesn't grow full. A filled data disk will not result in data corruption, but it may well prevent useful activity from occurring. If the disk holding the WAL files grows full, database server panic and consequent shutdown may occur. 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 for more information about that. Some file systems perform badly when they are almost full, so do not wait until the disk is completely full to take action. 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 space entirely.