database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Create a "relation mapping" infrastructure to support changing the relfilenodes

Browse Source 
of shared or nailed system catalogs.  This has two key benefits:

* The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs.

* We no longer have to use an unsafe reindex-in-place approach for reindexing
  shared catalogs.

CLUSTER on nailed catalogs now works too, although I left it disabled on
shared catalogs because the resulting pg_index.indisclustered update would
only be visible in one database.

Since reindexing shared system catalogs is now fully transactional and
crash-safe, the former special cases in REINDEX behavior have been removed;
shared catalogs are treated the same as non-shared.

This commit does not do anything about the recently-discussed problem of
deadlocks between VACUUM FULL/CLUSTER on a system catalog and other
concurrent queries; will address that in a separate patch.  As a stopgap,
parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid
such failures during the regression tests.
This commit is contained in:
Tom Lane
2010-02-07 20:48:13 +00:00
parent 7fc30c488f
commit b9b8831ad6
54 changed files with 2316 additions and 585 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
doc/src/sgml/diskusage.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.19 2010/02/03 17:25:05 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.20 2010/02/07 20:48:09 tgl Exp $ -->
<chapter id="diskusage">
<title>Monitoring Disk Usage</title>
@ -29,30 +29,31 @@
</para>
<para>
You can monitor disk space three ways: using
SQL functions listed in <xref linkend="functions-admin-dbsize">,
using <command>VACUUM</> information, and from the command line
using the tools in <filename>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.
You can monitor disk space in three ways:
using the SQL functions listed in <xref linkend="functions-admin-dbsize">,
using the tools in <filename>contrib/oid2name</>, or
using manual inspection of the system catalogs.
The SQL functions are the easiest to use and are generally recommended.
<filename>contrib/oid2name</> is described in <xref linkend="oid2name">.
The remainder of this section shows how to do it by inspection of the
system catalogs.
</para>
<para>
Using <application>psql</> on a recently vacuumed or analyzed database,
you can issue queries to see the disk usage of any table:
<programlisting>
SELECT relfilenode, relpages FROM pg_class WHERE relname = 'customer';
SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
relfilenode | relpages
-------------+----------
16806 | 60
pg_relation_filepath | relpages
----------------------+----------
base/16384/16806 | 60
(1 row)
</programlisting>
Each page is typically 8 kilobytes. (Remember, <structfield>relpages</>
is only updated by <command>VACUUM</>, <command>ANALYZE</>, and
a few DDL commands such as <command>CREATE INDEX</>.) The
<structfield>relfilenode</> value is of interest if you want to examine
the table's disk file directly.
a few DDL commands such as <command>CREATE INDEX</>.) The file pathname
is of interest if you want to examine the table's disk file directly.
</para>
<para>
@ -107,11 +108,6 @@ ORDER BY relpages DESC;
customer | 3144
</programlisting>
</para>
<para>
You can also use <filename>contrib/oid2name</> to show disk usage; see
<xref linkend="oid2name"> for more details and examples.
</para>
</sect1>
<sect1 id="disk-full">