2010-09-20 22:08:53 +02:00
|
|
|
<!-- doc/src/sgml/pgstattuple.sgml -->
|
2007-11-11 00:30:46 +01:00
|
|
|
|
2011-05-08 04:29:20 +02:00
|
|
|
<sect1 id="pgstattuple" xreflabel="pgstattuple">
|
2023-01-20 20:01:59 +01:00
|
|
|
<title>pgstattuple — obtain tuple-level statistics</title>
|
2007-12-10 06:32:51 +01:00
|
|
|
|
2007-11-11 00:30:46 +01:00
|
|
|
<indexterm zone="pgstattuple">
|
|
|
|
|
<primary>pgstattuple</primary>
|
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
|
|
<para>
|
2007-12-10 06:32:51 +01:00
|
|
|
The <filename>pgstattuple</filename> module provides various functions to
|
|
|
|
|
obtain tuple-level statistics.
|
2007-11-11 00:30:46 +01:00
|
|
|
</para>
|
|
|
|
|
|
2016-09-30 04:13:38 +02:00
|
|
|
<para>
|
2017-11-02 17:12:23 +01:00
|
|
|
Because these functions return detailed page-level information, access is
|
|
|
|
|
restricted by default. By default, only the
|
|
|
|
|
role <literal>pg_stat_scan_tables</literal> has <literal>EXECUTE</literal>
|
|
|
|
|
privilege. Superusers of course bypass this restriction. After the
|
|
|
|
|
extension has been installed, users may issue <command>GRANT</command>
|
|
|
|
|
commands to change the privileges on the functions to allow others to
|
|
|
|
|
execute them. However, it might be preferable to add those users to
|
|
|
|
|
the <literal>pg_stat_scan_tables</literal> role instead.
|
2016-09-30 04:13:38 +02:00
|
|
|
</para>
|
|
|
|
|
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect2 id="pgstattuple-funcs">
|
2007-11-11 00:30:46 +01:00
|
|
|
<title>Functions</title>
|
|
|
|
|
|
2007-12-10 06:32:51 +01:00
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
2014-05-07 03:28:58 +02:00
|
|
|
<indexterm>
|
|
|
|
|
<primary>pgstattuple</primary>
|
|
|
|
|
</indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstattuple(regclass) returns record</function>
|
2007-12-10 06:32:51 +01:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
<function>pgstattuple</function> returns a relation's physical length,
|
2017-10-09 03:44:17 +02:00
|
|
|
percentage of <quote>dead</quote> tuples, and other info. This may help users
|
2007-12-10 06:32:51 +01:00
|
|
|
to determine whether vacuum is necessary or not. The argument is the
|
2013-07-18 20:50:20 +02:00
|
|
|
target relation's name (optionally schema-qualified) or OID.
|
2007-12-10 06:32:51 +01:00
|
|
|
For example:
|
2009-05-18 13:08:24 +02:00
|
|
|
<programlisting>
|
2015-08-06 05:03:45 +02:00
|
|
|
test=> SELECT * FROM pgstattuple('pg_catalog.pg_proc');
|
2007-11-11 00:30:46 +01:00
|
|
|
-[ RECORD 1 ]------+-------
|
|
|
|
|
table_len | 458752
|
|
|
|
|
tuple_count | 1470
|
|
|
|
|
tuple_len | 438896
|
|
|
|
|
tuple_percent | 95.67
|
|
|
|
|
dead_tuple_count | 11
|
|
|
|
|
dead_tuple_len | 3157
|
|
|
|
|
dead_tuple_percent | 0.69
|
|
|
|
|
free_space | 8932
|
|
|
|
|
free_percent | 1.95
|
2009-05-18 13:08:24 +02:00
|
|
|
</programlisting>
|
2017-11-23 15:39:47 +01:00
|
|
|
The output columns are described in <xref linkend="pgstattuple-columns"/>.
|
2007-11-11 00:30:46 +01:00
|
|
|
</para>
|
2007-12-10 06:32:51 +01:00
|
|
|
|
2009-05-18 13:08:24 +02:00
|
|
|
<table id="pgstattuple-columns">
|
2011-01-29 19:00:18 +01:00
|
|
|
<title><function>pgstattuple</function> Output Columns</title>
|
2007-12-10 06:32:51 +01:00
|
|
|
<tgroup cols="3">
|
2007-11-11 00:30:46 +01:00
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>Column</entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry>Type</entry>
|
2007-11-11 15:23:18 +01:00
|
|
|
<entry>Description</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
</thead>
|
2007-12-10 06:32:51 +01:00
|
|
|
|
2007-11-11 00:30:46 +01:00
|
|
|
<tbody>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>table_len</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Physical relation length in bytes</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>tuple_count</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of live tuples</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>tuple_len</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Total length of live tuples in bytes</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>tuple_percent</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Percentage of live tuples</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>dead_tuple_count</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of dead tuples</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>dead_tuple_len</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Total length of dead tuples in bytes</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>dead_tuple_percent</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Percentage of dead tuples</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>free_space</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Total free space in bytes</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
|
|
|
|
<row>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry><structfield>free_percent</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Percentage of free space</entry>
|
2007-11-11 00:30:46 +01:00
|
|
|
</row>
|
2007-12-10 06:32:51 +01:00
|
|
|
|
2007-11-11 00:30:46 +01:00
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
|
2016-12-27 17:23:46 +01:00
|
|
|
<note>
|
2017-06-12 15:51:18 +02:00
|
|
|
<para>
|
|
|
|
|
The <literal>table_len</literal> will always be greater than the sum
|
|
|
|
|
of the <literal>tuple_len</literal>, <literal>dead_tuple_len</literal>
|
|
|
|
|
and <literal>free_space</literal>. The difference is accounted for by
|
|
|
|
|
fixed page overhead, the per-page table of pointers to tuples, and
|
|
|
|
|
padding to ensure that tuples are correctly aligned.
|
|
|
|
|
</para>
|
2016-12-27 17:23:46 +01:00
|
|
|
</note>
|
|
|
|
|
|
2007-11-11 00:30:46 +01:00
|
|
|
<para>
|
2007-12-10 06:32:51 +01:00
|
|
|
<function>pgstattuple</function> acquires only a read lock on the
|
|
|
|
|
relation. So the results do not reflect an instantaneous snapshot;
|
|
|
|
|
concurrent updates will affect them.
|
2007-11-11 00:30:46 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstattuple</function> judges a tuple is <quote>dead</quote> if
|
|
|
|
|
<function>HeapTupleSatisfiesDirty</function> returns false.
|
2007-11-11 00:30:46 +01:00
|
|
|
</para>
|
2007-12-10 06:32:51 +01:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstattuple(text) returns record</function>
|
2007-12-10 06:32:51 +01:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
2013-07-18 20:50:20 +02:00
|
|
|
This is the same as <function>pgstattuple(regclass)</function>, except
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
that the target relation is specified as TEXT. This function is kept
|
2013-07-18 20:50:20 +02:00
|
|
|
because of backward-compatibility so far, and will be deprecated in
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
some future release.
|
2007-12-10 06:32:51 +01:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
2013-07-04 17:33:08 +02:00
|
|
|
<indexterm>
|
|
|
|
|
<primary>pgstatindex</primary>
|
|
|
|
|
</indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstatindex(regclass) returns record</function>
|
2007-12-10 06:32:51 +01:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
<function>pgstatindex</function> returns a record showing information
|
2010-08-17 06:37:21 +02:00
|
|
|
about a B-tree index. For example:
|
2010-07-29 21:34:41 +02:00
|
|
|
<programlisting>
|
2015-08-06 05:03:45 +02:00
|
|
|
test=> SELECT * FROM pgstatindex('pg_cast_oid_index');
|
2007-11-11 00:30:46 +01:00
|
|
|
-[ RECORD 1 ]------+------
|
|
|
|
|
version | 2
|
|
|
|
|
tree_level | 0
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
index_size | 16384
|
2007-11-11 00:30:46 +01:00
|
|
|
root_block_no | 1
|
|
|
|
|
internal_pages | 0
|
|
|
|
|
leaf_pages | 1
|
|
|
|
|
empty_pages | 0
|
|
|
|
|
deleted_pages | 0
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
avg_leaf_density | 54.27
|
2007-11-11 00:30:46 +01:00
|
|
|
leaf_fragmentation | 0
|
2010-07-29 21:34:41 +02:00
|
|
|
</programlisting>
|
|
|
|
|
</para>
|
2007-12-10 06:32:51 +01:00
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The output columns are:
|
|
|
|
|
|
2010-08-10 22:42:01 +02:00
|
|
|
<informaltable>
|
2007-12-10 06:32:51 +01:00
|
|
|
<tgroup cols="3">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>Column</entry>
|
|
|
|
|
<entry>Type</entry>
|
|
|
|
|
<entry>Description</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>version</structfield></entry>
|
|
|
|
|
<entry><type>integer</type></entry>
|
2010-08-17 06:37:21 +02:00
|
|
|
<entry>B-tree version number</entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>tree_level</structfield></entry>
|
|
|
|
|
<entry><type>integer</type></entry>
|
|
|
|
|
<entry>Tree level of the root page</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>index_size</structfield></entry>
|
2008-03-21 04:23:30 +01:00
|
|
|
<entry><type>bigint</type></entry>
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
<entry>Total index size in bytes</entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>root_block_no</structfield></entry>
|
2008-03-21 04:23:30 +01:00
|
|
|
<entry><type>bigint</type></entry>
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
<entry>Location of root page (zero if none)</entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>internal_pages</structfield></entry>
|
2008-03-21 04:23:30 +01:00
|
|
|
<entry><type>bigint</type></entry>
|
2017-10-09 03:44:17 +02:00
|
|
|
<entry>Number of <quote>internal</quote> (upper-level) pages</entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>leaf_pages</structfield></entry>
|
2008-03-21 04:23:30 +01:00
|
|
|
<entry><type>bigint</type></entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry>Number of leaf pages</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>empty_pages</structfield></entry>
|
2008-03-21 04:23:30 +01:00
|
|
|
<entry><type>bigint</type></entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry>Number of empty pages</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>deleted_pages</structfield></entry>
|
2008-03-21 04:23:30 +01:00
|
|
|
<entry><type>bigint</type></entry>
|
2007-12-10 06:32:51 +01:00
|
|
|
<entry>Number of deleted pages</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>avg_leaf_density</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Average density of leaf pages</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>leaf_fragmentation</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Leaf page fragmentation</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
2010-08-10 22:42:01 +02:00
|
|
|
</informaltable>
|
|
|
|
|
</para>
|
2007-12-10 06:32:51 +01:00
|
|
|
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
The reported <literal>index_size</literal> will normally correspond to one more
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
page than is accounted for by <literal>internal_pages + leaf_pages +
|
|
|
|
|
empty_pages + deleted_pages</literal>, because it also includes the
|
|
|
|
|
index's metapage.
|
|
|
|
|
</para>
|
|
|
|
|
|
2007-12-10 06:32:51 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
As with <function>pgstattuple</function>, the results are accumulated
|
2007-12-10 06:32:51 +01:00
|
|
|
page-by-page, and should not be expected to represent an
|
|
|
|
|
instantaneous snapshot of the whole index.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2013-07-18 20:50:20 +02:00
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstatindex(text) returns record</function>
|
2013-07-18 20:50:20 +02:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
This is the same as <function>pgstatindex(regclass)</function>, except
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
that the target index is specified as TEXT. This function is kept
|
2013-07-18 20:50:20 +02:00
|
|
|
because of backward-compatibility so far, and will be deprecated in
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
some future release.
|
2013-07-18 20:50:20 +02:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2012-12-05 08:58:03 +01:00
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
2013-07-04 17:33:08 +02:00
|
|
|
<indexterm>
|
|
|
|
|
<primary>pgstatginindex</primary>
|
|
|
|
|
</indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstatginindex(regclass) returns record</function>
|
2012-12-05 08:58:03 +01:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
<function>pgstatginindex</function> returns a record showing information
|
|
|
|
|
about a GIN index. For example:
|
|
|
|
|
<programlisting>
|
2015-08-06 05:03:45 +02:00
|
|
|
test=> SELECT * FROM pgstatginindex('test_gin_index');
|
2012-12-05 08:58:03 +01:00
|
|
|
-[ RECORD 1 ]--+--
|
|
|
|
|
version | 1
|
|
|
|
|
pending_pages | 0
|
|
|
|
|
pending_tuples | 0
|
|
|
|
|
</programlisting>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The output columns are:
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="3">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>Column</entry>
|
|
|
|
|
<entry>Type</entry>
|
|
|
|
|
<entry>Description</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>version</structfield></entry>
|
|
|
|
|
<entry><type>integer</type></entry>
|
|
|
|
|
<entry>GIN version number</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>pending_pages</structfield></entry>
|
|
|
|
|
<entry><type>integer</type></entry>
|
|
|
|
|
<entry>Number of pages in the pending list</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>pending_tuples</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of tuples in the pending list</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2017-02-03 20:35:25 +01:00
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
|
|
|
|
<indexterm>
|
|
|
|
|
<primary>pgstathashindex</primary>
|
|
|
|
|
</indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstathashindex(regclass) returns record</function>
|
2017-02-03 20:35:25 +01:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
<function>pgstathashindex</function> returns a record showing information
|
|
|
|
|
about a HASH index. For example:
|
|
|
|
|
<programlisting>
|
|
|
|
|
test=> select * from pgstathashindex('con_hash_index');
|
|
|
|
|
-[ RECORD 1 ]--+-----------------
|
hash: Increase the number of possible overflow bitmaps by 8x.
Per a report from AP, it's not that hard to exhaust the supply of
bitmap pages if you create a table with a hash index and then insert a
few billion rows - and then you start getting errors when you try to
insert additional rows. In the particular case reported by AP,
there's another fix that we can make to improve recycling of overflow
pages, which is another way to avoid the error, but there may be other
cases where this problem happens and that fix won't help. So let's
buy ourselves as much headroom as we can without rearchitecting
anything.
The comments claim that the old limit was 64GB, but it was really
only 32GB, because we didn't use all the bits in the page for bitmap
bits - only the largest power of 2 that could fit after deducting
space for the page header and so forth. Thus, we have 4kB per page
for bitmap bits, not 8kB. The new limit is thus actually 8 times the
old *real* limit but only 4 times the old *purported* limit.
Since this breaks on-disk compatibility, bump HASH_VERSION. We've
already done this earlier in this release cycle, so this doesn't cause
any incremental inconvenience for people using pg_upgrade from
releases prior to v10. However, users who use pg_upgrade to reach
10beta3 or later from 10beta2 or earlier will need to REINDEX any hash
indexes again.
Amit Kapila and Robert Haas
Discussion: http://postgr.es/m/20170704105728.mwb72jebfmok2nm2@zip.com.au
2017-08-04 21:29:26 +02:00
|
|
|
version | 4
|
2017-02-03 20:35:25 +01:00
|
|
|
bucket_pages | 33081
|
|
|
|
|
overflow_pages | 0
|
|
|
|
|
bitmap_pages | 1
|
2017-04-12 17:53:00 +02:00
|
|
|
unused_pages | 32455
|
2017-02-03 20:35:25 +01:00
|
|
|
live_items | 10204006
|
|
|
|
|
dead_items | 0
|
|
|
|
|
free_percent | 61.8005949100872
|
|
|
|
|
</programlisting>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The output columns are:
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="3">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>Column</entry>
|
|
|
|
|
<entry>Type</entry>
|
|
|
|
|
<entry>Description</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>version</structfield></entry>
|
|
|
|
|
<entry><type>integer</type></entry>
|
|
|
|
|
<entry>HASH version number</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>bucket_pages</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of bucket pages</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>overflow_pages</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of overflow pages</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>bitmap_pages</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of bitmap pages</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
2017-04-12 17:53:00 +02:00
|
|
|
<entry><structfield>unused_pages</structfield></entry>
|
2017-02-03 20:35:25 +01:00
|
|
|
<entry><type>bigint</type></entry>
|
2017-04-12 17:53:00 +02:00
|
|
|
<entry>Number of unused pages</entry>
|
2017-02-03 20:35:25 +01:00
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>live_items</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of live tuples</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>dead_tuples</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of dead tuples</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>free_percent</structfield></entry>
|
|
|
|
|
<entry><type>float</type></entry>
|
|
|
|
|
<entry>Percentage of free space</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2007-12-10 06:32:51 +01:00
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
2013-07-04 17:33:08 +02:00
|
|
|
<indexterm>
|
|
|
|
|
<primary>pg_relpages</primary>
|
|
|
|
|
</indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pg_relpages(regclass) returns bigint</function>
|
2007-12-10 06:32:51 +01:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
<function>pg_relpages</function> returns the number of pages in the
|
|
|
|
|
relation.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2013-07-18 20:50:20 +02:00
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pg_relpages(text) returns bigint</function>
|
2013-07-18 20:50:20 +02:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
This is the same as <function>pg_relpages(regclass)</function>, except
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
that the target relation is specified as TEXT. This function is kept
|
2013-07-18 20:50:20 +02:00
|
|
|
because of backward-compatibility so far, and will be deprecated in
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
some future release.
|
2013-07-18 20:50:20 +02:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2015-05-13 07:31:04 +02:00
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
|
|
|
|
<indexterm>
|
|
|
|
|
<primary>pgstattuple_approx</primary>
|
|
|
|
|
</indexterm>
|
2017-10-09 03:44:17 +02:00
|
|
|
<function>pgstattuple_approx(regclass) returns record</function>
|
2015-05-13 07:31:04 +02:00
|
|
|
</term>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
<function>pgstattuple_approx</function> is a faster alternative to
|
|
|
|
|
<function>pgstattuple</function> that returns approximate results.
|
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
Dead or half-dead index leaf pages were incorrectly reported as live, as a
consequence of a code rearrangement I made (during a moment of severe brain
fade, evidently) in commit d287818eb514d431.
The index metapage was not counted in index_size, causing that result to
not agree with the actual index size on-disk.
Index root pages were not counted in internal_pages, which is inconsistent
compared to the case of a root that's also a leaf (one-page index), where
the root would be counted in leaf_pages. Aside from that inconsistency,
this could lead to additional transient discrepancies between the reported
page counts and index_size, since it's possible for pgstatindex's scan to
see zero or multiple pages marked as BTP_ROOT, if the root moves due to
a split during the scan. With these fixes, index_size will always be
exactly one page more than the sum of the displayed page counts.
Also, the index_size result was incorrectly documented as being measured in
pages; it's always been measured in bytes. (While fixing that, I couldn't
resist doing some small additional wordsmithing on the pgstattuple docs.)
Including the metapage causes the reported index_size to not be zero for
an empty index. To preserve the desired property that the pgstattuple
regression test results are platform-independent (ie, BLCKSZ configuration
independent), scale the index_size result in the regression tests.
The documentation issue was reported by Otsuka Kenji, and the inconsistent
root page counting by Peter Geoghegan; the other problems noted by me.
Back-patch to all supported branches, because this has been broken for
a long time.
2016-02-18 21:40:35 +01:00
|
|
|
The argument is the target relation's name or OID.
|
2015-05-13 07:31:04 +02:00
|
|
|
For example:
|
|
|
|
|
<programlisting>
|
2015-08-06 05:03:45 +02:00
|
|
|
test=> SELECT * FROM pgstattuple_approx('pg_catalog.pg_proc'::regclass);
|
2015-05-13 07:31:04 +02:00
|
|
|
-[ RECORD 1 ]--------+-------
|
|
|
|
|
table_len | 573440
|
|
|
|
|
scanned_percent | 2
|
|
|
|
|
approx_tuple_count | 2740
|
|
|
|
|
approx_tuple_len | 561210
|
|
|
|
|
approx_tuple_percent | 97.87
|
|
|
|
|
dead_tuple_count | 0
|
|
|
|
|
dead_tuple_len | 0
|
|
|
|
|
dead_tuple_percent | 0
|
|
|
|
|
approx_free_space | 11996
|
|
|
|
|
approx_free_percent | 2.09
|
|
|
|
|
</programlisting>
|
2017-11-23 15:39:47 +01:00
|
|
|
The output columns are described in <xref linkend="pgstatapprox-columns"/>.
|
2015-05-13 07:31:04 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Whereas <function>pgstattuple</function> always performs a
|
|
|
|
|
full-table scan and returns an exact count of live and dead tuples
|
|
|
|
|
(and their sizes) and free space, <function>pgstattuple_approx</function>
|
|
|
|
|
tries to avoid the full-table scan and returns exact dead tuple
|
|
|
|
|
statistics along with an approximation of the number and
|
|
|
|
|
size of live tuples and free space.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
It does this by skipping pages that have only visible tuples
|
|
|
|
|
according to the visibility map (if a page has the corresponding VM
|
|
|
|
|
bit set, then it is assumed to contain no dead tuples). For such
|
|
|
|
|
pages, it derives the free space value from the free space map, and
|
|
|
|
|
assumes that the rest of the space on the page is taken up by live
|
2019-05-07 06:00:24 +02:00
|
|
|
tuples.
|
2015-05-13 07:31:04 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
For pages that cannot be skipped, it scans each tuple, recording its
|
|
|
|
|
presence and size in the appropriate counters, and adding up the
|
|
|
|
|
free space on the page. At the end, it estimates the total number of
|
|
|
|
|
live tuples based on the number of pages and tuples scanned (in the
|
|
|
|
|
same way that VACUUM estimates pg_class.reltuples).
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<table id="pgstatapprox-columns">
|
|
|
|
|
<title><function>pgstattuple_approx</function> Output Columns</title>
|
|
|
|
|
<tgroup cols="3">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>Column</entry>
|
|
|
|
|
<entry>Type</entry>
|
|
|
|
|
<entry>Description</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>table_len</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Physical relation length in bytes (exact)</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>scanned_percent</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Percentage of table scanned</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
2015-05-21 13:51:52 +02:00
|
|
|
<entry><structfield>approx_tuple_count</structfield></entry>
|
2015-05-13 07:31:04 +02:00
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of live tuples (estimated)</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
2015-05-21 13:51:52 +02:00
|
|
|
<entry><structfield>approx_tuple_len</structfield></entry>
|
2015-05-13 07:31:04 +02:00
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Total length of live tuples in bytes (estimated)</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
2015-05-21 13:51:52 +02:00
|
|
|
<entry><structfield>approx_tuple_percent</structfield></entry>
|
2015-05-13 07:31:04 +02:00
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Percentage of live tuples</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>dead_tuple_count</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Number of dead tuples (exact)</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>dead_tuple_len</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Total length of dead tuples in bytes (exact)</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>dead_tuple_percent</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Percentage of dead tuples</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>approx_free_space</structfield></entry>
|
|
|
|
|
<entry><type>bigint</type></entry>
|
|
|
|
|
<entry>Total free space in bytes (estimated)</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><structfield>approx_free_percent</structfield></entry>
|
|
|
|
|
<entry><type>float8</type></entry>
|
|
|
|
|
<entry>Percentage of free space</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
In the above output, the free space figures may not match the
|
|
|
|
|
<function>pgstattuple</function> output exactly, because the free
|
|
|
|
|
space map gives us an exact figure, but is not guaranteed to be
|
|
|
|
|
accurate to the byte.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2007-12-10 06:32:51 +01:00
|
|
|
</variablelist>
|
2007-11-11 00:30:46 +01:00
|
|
|
</sect2>
|
|
|
|
|
|
2023-01-09 21:08:24 +01:00
|
|
|
<sect2 id="pgstattuple-authors">
|
2008-03-21 04:23:30 +01:00
|
|
|
<title>Authors</title>
|
2007-12-10 06:32:51 +01:00
|
|
|
|
2007-11-11 00:30:46 +01:00
|
|
|
<para>
|
2015-05-13 07:31:04 +02:00
|
|
|
Tatsuo Ishii, Satoshi Nagayasu and Abhijit Menon-Sen
|
2007-11-11 00:30:46 +01:00
|
|
|
</para>
|
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
|
|
</sect1>
|
