rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/doc/src/sgml/monitoring.sgml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

7286 lines
247 KiB
Plaintext
Raw Normal View History

Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
<!-- doc/src/sgml/monitoring.sgml -->
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<chapter id="monitoring">
<title>Monitoring Database Activity</title>
Add/edit index entries.
2003-08-31 19:32:24 +02:00
<indexterm zone="monitoring">
<primary>monitoring</primary>
<secondary>database activity</secondary>
</indexterm>
<indexterm zone="monitoring">
<primary>database activity</primary>
<secondary>monitoring</secondary>
</indexterm>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<para>
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
A database administrator frequently wonders, <quote>What is the system
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
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
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
<productname>PostgreSQL</productname>'s cumulative statistics system,
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
but one should not neglect regular Unix monitoring programs such as
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<command>ps</command>, <command>top</command>, <command>iostat</command>, and <command>vmstat</command>.
More minor updates and copy-editing.
2004-12-28 20:08:58 +01:00
Also, once one has identified a
Update documentation on may/can/might: Standard English uses "may", "can", and "might" in different ways: may - permission, "You may borrow my rake." can - ability, "I can lift that log." might - possibility, "It might rain today." Unfortunately, in conversational English, their use is often mixed, as in, "You may use this variable to do X", when in fact, "can" is a better choice. Similarly, "It may crash" is better stated, "It might crash". Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
poorly-performing query, further investigation might be needed using
Improve <xref> vs. <command> formatting in the documentation SQL commands are generally marked up as <command>, except when a link to a reference page is used using <xref>. But the latter doesn't create monospace markup, so this looks strange especially when a paragraph contains a mix of links and non-links. We considered putting <command> in the <refentrytitle> on the target side, but that creates some formatting side effects elsewhere. Generally, it seems safer to solve this on the link source side. We can't put the <xref> inside the <command>; the DTD doesn't allow this. DocBook 5 would allow the <command> to have the linkend attribute itself, but we are not there yet. So to solve this for now, convert the <xref>s to <link> plus <command>. This gives the correct look and also gives some more flexibility what we can put into the link text (e.g., subcommands or other clauses). In the future, these could then be converted to DocBook 5 style. I haven't converted absolutely all xrefs to SQL command reference pages, only those where we care about the appearance of the link text or where it was otherwise appropriate to make the appearance match a bit better. Also in some cases, the links where repetitive, so in those cases the links where just removed and replaced by a plain <command>. In cases where we just want the link and don't specifically care about the generated link text (typically phrased "for further information see <xref ...>") the xref is kept. Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
<productname>PostgreSQL</productname>'s <link linkend="sql-explain"><command>EXPLAIN</command></link> command.
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="using-explain"/> discusses <command>EXPLAIN</command>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
and other methods for understanding the behavior of an individual
query.
</para>
<sect1 id="monitoring-ps">
Properly capitalize documentation headings; some only had initial-word capitalization.
2011-01-29 19:00:18 +01:00
<title>Standard Unix Tools</title>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
Add some more index entries.
2001-11-12 20:19:39 +01:00
<indexterm zone="monitoring-ps">
<primary>ps</primary>
<secondary>to monitor activity</secondary>
</indexterm>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<para>
Proofreading improvements for the Administration documentation book.
2010-02-03 18:25:06 +01:00
On most Unix platforms, <productname>PostgreSQL</productname> modifies its
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
command title as reported by <command>ps</command>, so that individual server
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
processes can readily be identified. A sample display is
<screen>
$ ps auxww | grep ^postgres
Update example of process titles shown by "ps". This example was quite old: it lacked the WAL writer and autovac launcher as well as the more recently added checkpointer. Linux "ps" seems to show slightly different stuff now too.
2012-05-12 00:33:39 +02:00
postgres 15551 0.0 0.1 57536 7132 pts/0 S 18:02 0:00 postgres -i
Sync process names between ps and pg_stat_activity Remove gratuitous differences in the process names shown in pg_stat_activity.backend_type and the ps output. Reviewed-by: Takayuki Tsunakawa <tsunakawa.takay@jp.fujitsu.com>
2017-09-20 03:15:09 +02:00
postgres 15554 0.0 0.0 57536 1184 ? Ss 18:02 0:00 postgres: background writer
postgres 15555 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: checkpointer
postgres 15556 0.0 0.0 57536 916 ? Ss 18:02 0:00 postgres: walwriter
postgres 15557 0.0 0.0 58504 2244 ? Ss 18:02 0:00 postgres: autovacuum launcher
Update example of process titles shown by "ps". This example was quite old: it lacked the WAL writer and autovac launcher as well as the more recently added checkpointer. Linux "ps" seems to show slightly different stuff now too.
2012-05-12 00:33:39 +02:00
postgres 15582 0.0 0.0 58772 3080 ? Ss 18:04 0:00 postgres: joe runbug 127.0.0.1 idle
postgres 15606 0.0 0.0 58772 3052 ? Ss 18:07 0:00 postgres: tgl regression [local] SELECT waiting
postgres 15610 0.0 0.0 58772 3056 ? Ss 18:07 0:00 postgres: tgl regression [local] idle in transaction
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</screen>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
(The appropriate invocation of <command>ps</command> varies across different
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
platforms, as do the details of what is shown. This example is from a
recent Linux system.) The first process listed here is the
docs: replace 'master' with 'primary' where appropriate. Also changed "in the primary" to "on the primary", and added a few "the" before "primary". Author: Andres Freund Reviewed-By: David Steele Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
2020-06-15 19:12:58 +02:00
primary server process. The command arguments
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
shown for it are the same ones used when it was launched. The next four
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
processes are background worker processes automatically launched by the
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
primary process. (The <quote>autovacuum launcher</quote> process will not
be present if you have set the system not to run autovacuum.)
Update example of process titles shown by "ps". This example was quite old: it lacked the WAL writer and autovac launcher as well as the more recently added checkpointer. Linux "ps" seems to show slightly different stuff now too.
2012-05-12 00:33:39 +02:00
Each of the remaining
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
processes is a server process handling one client connection. Each such
process sets its command line display in the form
<screen>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
postgres: <replaceable>user</replaceable> <replaceable>database</replaceable> <replaceable>host</replaceable> <replaceable>activity</replaceable>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</screen>
Proofreading improvements for the Administration documentation book.
2010-02-03 18:25:06 +01:00
The user, database, and (client) host items remain the same for
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
the life of the client connection, but the activity indicator changes.
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The activity can be <literal>idle</literal> (i.e., waiting for a client command),
<literal>idle in transaction</literal> (waiting for client inside a <command>BEGIN</command> block),
or a command type name such as <literal>SELECT</literal>. Also,
<literal>waiting</literal> is appended if the server process is presently waiting
Proofreading improvements for the Administration documentation book.
2010-02-03 18:25:06 +01:00
on a lock held by another session. In the above example we can infer
Update example of process titles shown by "ps". This example was quite old: it lacked the WAL writer and autovac launcher as well as the more recently added checkpointer. Linux "ps" seems to show slightly different stuff now too.
2012-05-12 00:33:39 +02:00
that process 15606 is waiting for process 15610 to complete its transaction
and thereby release some lock. (Process 15610 must be the blocker, because
there is no other active session. In more complicated cases it would be
necessary to look into the
<link linkend="view-pg-locks"><structname>pg_locks</structname></link>
system view to determine who is blocking whom.)
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
Update ps status display information for Solaris, from Tom Lane.
2001-11-29 21:26:55 +01:00
Add cluster_name GUC which is included in process titles if set. When running several postgres clusters on one OS instance it's often inconveniently hard to identify which "postgres" process belongs to which postgres instance. Add the cluster_name GUC, whose value will be included as part of the process titles if set. With that processes can more easily identified using tools like 'ps'. To avoid problems with encoding mismatches between postgresql.conf, consoles, and individual databases replace non-ASCII chars in the name with question marks. The length is limited to NAMEDATALEN to make it less likely to truncate important information at the end of the status. Thomas Munro, with some adjustments by me and review by a host of people.
2014-06-29 14:15:09 +02:00
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
If <xref linkend="guc-cluster-name"/> has been configured the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
cluster name will also be shown in <command>ps</command> output:
Add cluster_name GUC which is included in process titles if set. When running several postgres clusters on one OS instance it's often inconveniently hard to identify which "postgres" process belongs to which postgres instance. Add the cluster_name GUC, whose value will be included as part of the process titles if set. With that processes can more easily identified using tools like 'ps'. To avoid problems with encoding mismatches between postgresql.conf, consoles, and individual databases replace non-ASCII chars in the name with question marks. The length is limited to NAMEDATALEN to make it less likely to truncate important information at the end of the status. Thomas Munro, with some adjustments by me and review by a host of people.
2014-06-29 14:15:09 +02:00
<screen>
$ psql -c 'SHOW cluster_name'
cluster_name
--------------
server1
(1 row)
$ ps aux|grep server1
Sync process names between ps and pg_stat_activity Remove gratuitous differences in the process names shown in pg_stat_activity.backend_type and the ps output. Reviewed-by: Takayuki Tsunakawa <tsunakawa.takay@jp.fujitsu.com>
2017-09-20 03:15:09 +02:00
postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: server1: background writer
Add cluster_name GUC which is included in process titles if set. When running several postgres clusters on one OS instance it's often inconveniently hard to identify which "postgres" process belongs to which postgres instance. Add the cluster_name GUC, whose value will be included as part of the process titles if set. With that processes can more easily identified using tools like 'ps'. To avoid problems with encoding mismatches between postgresql.conf, consoles, and individual databases replace non-ASCII chars in the name with question marks. The length is limited to NAMEDATALEN to make it less likely to truncate important information at the end of the status. Thomas Munro, with some adjustments by me and review by a host of people.
2014-06-29 14:15:09 +02:00
...
</screen>
</para>
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
If you have turned off <xref linkend="guc-update-process-title"/> then the
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
activity indicator is not updated; the process title is set only once
Proofreading improvements for the Administration documentation book.
2010-02-03 18:25:06 +01:00
when a new process is launched. On some platforms this saves a measurable
amount of per-command overhead; on others it's insignificant.
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
</para>
Update ps status display information for Solaris, from Tom Lane.
2001-11-29 21:26:55 +01:00
<tip>
<para>
<productname>Solaris</productname> requires special handling. You must
use <command>/usr/ucb/ps</command>, rather than
Another big editing pass for consistent content and presentation.
2003-03-24 15:32:51 +01:00
<command>/bin/ps</command>. You also must use two <option>w</option>
Update ps status display information for Solaris, from Tom Lane.
2001-11-29 21:26:55 +01:00
flags, not just one. In addition, your original invocation of the
Merge postmaster and postgres command into just postgres. postmaster symlink is kept for now for compatibility. To call single-user mode, use postgres --single.
2006-06-18 17:38:37 +02:00
<command>postgres</command> command must have a shorter
Update ps status display information for Solaris, from Tom Lane.
2001-11-29 21:26:55 +01:00
<command>ps</command> status display than that provided by each
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
server process. If you fail to do all three things, the <command>ps</command>
output for each server process will be the original <command>postgres</command>
Cleanup of new ps markup.
2001-11-29 21:43:43 +01:00
command line.
Update ps status display information for Solaris, from Tom Lane.
2001-11-29 21:26:55 +01:00
</para>
</tip>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</sect1>
<sect1 id="monitoring-stats">
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
<title>The Cumulative Statistics System</title>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
Add some more index entries.
2001-11-12 20:19:39 +01:00
<indexterm zone="monitoring-stats">
<primary>statistics</primary>
</indexterm>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<para>
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
<productname>PostgreSQL</productname>'s <firstterm>cumulative statistics
system</firstterm> supports collection and reporting of information about
server activity. Presently, accesses to tables and indexes in both
disk-block and individual-row terms are counted. The total number of rows
in each table, and information about vacuum and analyze actions for each
table are also counted. If enabled, calls to user-defined functions and
the total time spent in each one are counted as well.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
</para>
<para>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<productname>PostgreSQL</productname> also supports reporting dynamic
information about exactly what is going on in the system right now, such as
the exact command currently being executed by other server processes, and
which other connections exist in the system. This facility is independent
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
of the cumulative statistics system.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
<sect2 id="monitoring-stats-setup">
Properly capitalize documentation headings; some only had initial-word capitalization.
2011-01-29 19:00:18 +01:00
<title>Statistics Collection Configuration</title>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<para>
Since collection of statistics adds some overhead to query execution,
the system can be configured to collect or not collect information.
Another big editing pass for consistent content and presentation.
2003-03-24 15:32:51 +01:00
This is controlled by configuration parameters that are normally set in
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<filename>postgresql.conf</filename>. (See <xref linkend="runtime-config"/> for
Another big editing pass for consistent content and presentation.
2003-03-24 15:32:51 +01:00
details about setting configuration parameters.)
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
The parameter <xref linkend="guc-track-activities"/> enables monitoring
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
of the current command being executed by any server process.
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
</para>
Expose track_iotiming data via the statistics collector. Ants Aasma's original patch to add timing information for buffer I/O requests exposed this data at the relation level, which was judged too costly. I've here exposed it at the database level instead.
2012-04-05 17:37:31 +02:00
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
The parameter <xref linkend="guc-track-counts"/> controls whether
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
cumulative statistics are collected about table and index accesses.
Expose track_iotiming data via the statistics collector. Ants Aasma's original patch to add timing information for buffer I/O requests exposed this data at the relation level, which was judged too costly. I've here exposed it at the database level instead.
2012-04-05 17:37:31 +02:00
</para>
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
The parameter <xref linkend="guc-track-functions"/> enables tracking of
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
usage of user-defined functions.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
<para>
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
The parameter <xref linkend="guc-track-io-timing"/> enables monitoring
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
of block read and write times.
Document that xact commit/abort stats are collected if any stat variable is set.
2006-02-14 03:03:44 +01:00
</para>
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Track total amounts of times spent writing and syncing WAL data to disk. This commit adds new GUC track_wal_io_timing. When this is enabled, the total amounts of time XLogWrite writes and issue_xlog_fsync syncs WAL data to disk are counted in pg_stat_wal. This information would be useful to check how much WAL write and sync affect the performance. Enabling track_wal_io_timing will make the server query the operating system for the current time every time WAL is written or synced, which may cause significant overhead on some platforms. To avoid such additional overhead in the server with track_io_timing enabled, this commit introduces track_wal_io_timing as a separate parameter from track_io_timing. Note that WAL write and sync activity by walreceiver has not been tracked yet. This commit makes the server also track the numbers of times XLogWrite writes and issue_xlog_fsync syncs WAL data to disk, in pg_stat_wal, regardless of the setting of track_wal_io_timing. This counters can be used to calculate the WAL write and sync time per request, for example. Bump PGSTAT_FILE_FORMAT_ID. Bump catalog version. Author: Masahiro Ikeda Reviewed-By: Japin Li, Hayato Kuroda, Masahiko Sawada, David Johnston, Fujii Masao Discussion: https://postgr.es/m/0509ad67b585a5b86a83d445dfa75392@oss.nttdata.com
2021-03-09 08:52:06 +01:00
<para>
The parameter <xref linkend="guc-track-wal-io-timing"/> enables monitoring
of WAL write times.
</para>
Document that xact commit/abort stats are collected if any stat variable is set.
2006-02-14 03:03:44 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Normally these parameters are set in <filename>postgresql.conf</filename> so
Document that xact commit/abort stats are collected if any stat variable is set.
2006-02-14 03:03:44 +01:00
that they apply to all server processes, but it is possible to turn
them on or off in individual sessions using the <xref
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
linkend="sql-set"/> command. (To prevent
More cross-reference work, other minor SGML fixes and improvements.
2004-03-26 04:18:28 +01:00
ordinary users from hiding their activity from the administrator,
only superusers are allowed to change these parameters with
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<command>SET</command>.)
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
<para>
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
Cumulative statistics are collected in shared memory. Every
Docs: Fix various mistakes and typos Author: Justin Pryzby Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
2022-04-11 10:48:48 +02:00
<productname>PostgreSQL</productname> process collects statistics locally,
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
then updates the shared data at appropriate intervals. When a server,
including a physical replica, shuts down cleanly, a permanent copy of the
statistics data is stored in the <filename>pg_stat</filename> subdirectory,
so that statistics can be retained across server restarts. In contrast,
when starting from an unclean shutdown (e.g., after an immediate shutdown,
a server crash, starting from a base backup, and point-in-time recovery),
all statistics counters are reset.
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
</para>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</sect2>
<sect2 id="monitoring-stats-views">
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<title>Viewing Statistics</title>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<para>
More minor updates and copy-editing.
2004-12-28 20:08:58 +01:00
Several predefined views, listed in <xref
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
linkend="monitoring-stats-dynamic-views-table"/>, are available to show
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
the current state of the system. There are also several other
views, listed in <xref
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
linkend="monitoring-stats-views-table"/>, available to show the accumulated
statistics. Alternatively, one can
build custom views using the underlying cumulative statistics functions, as
discussed in <xref linkend="monitoring-stats-functions"/>.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
<para>
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
When using the cumulative statistics views and functions to monitor
collected data, it is important to realize that the information does not
update instantaneously. Each individual server process flushes out
accumulated statistics to shared memory just before going idle, but not
more frequently than once per <varname>PGSTAT_MIN_INTERVAL</varname>
milliseconds (1 second unless altered while building the server); so a
query or transaction still in progress does not affect the displayed totals
and the displayed information lags behind actual activity. However,
current-query information collected by <varname>track_activities</varname>
is always up-to-date.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
<para>
Another important point is that when a server process is asked to display
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
any of the accumulated statistics, accessed values are cached until the end
of its current transaction in the default configuration. So the statistics
will show static information as long as you continue the current
transaction. Similarly, information about the current queries of all
sessions is collected when any such information is first requested within a
transaction, and the same information will be displayed throughout the
transaction. 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.
When analyzing statistics interactively, or with expensive queries, the
time delta between accesses to individual statistics can lead to
significant skew in the cached statistics. To minimize skew,
<varname>stats_fetch_consistency</varname> can be set to
<literal>snapshot</literal>, at the price of increased memory usage for
caching not-needed statistics data. Conversely, if it's known that
statistics are only accessed once, caching accessed statistics is
unnecessary and can be avoided by setting
<varname>stats_fetch_consistency</varname> to <literal>none</literal>.
doc: wording improvements Discussion: https://postgr.es/m/a5180360-ec04-ac58-25ce-3d795d3d1f6c@postgrespro.ru Author: Ekaterina Kiryanova Backpatch-through: master
2023-10-27 23:23:09 +02:00
You can invoke <function>pg_stat_clear_snapshot()</function> to discard the
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
current transaction's statistics snapshot or cached values (if any). The
next use of statistical information will (when in snapshot mode) cause a
new snapshot to be built or (when in cache mode) accessed statistics to be
cached.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
<para>
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
A transaction can also see its own statistics (not yet flushed out to the
shared memory statistics) in the views
<structname>pg_stat_xact_all_tables</structname>,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structname>pg_stat_xact_sys_tables</structname>,
<structname>pg_stat_xact_user_tables</structname>, and
<structname>pg_stat_xact_user_functions</structname>. These numbers do not act as
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
stated above; instead they update continuously throughout the transaction.
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
</para>
doc: Add security information about pg_stat_activity Add a basic note that some columns in pg_stat_activity and related views are not visible to all users. Discussion: https://www.postgresql.org/message-id/3018acd9-e5d8-1e85-5ed7-47276cd77569%402ndquadrant.com
2019-02-21 19:49:27 +01:00
<para>
Some of the information in the dynamic statistics views shown in <xref
linkend="monitoring-stats-dynamic-views-table"/> is security restricted.
Ordinary users can only see all the information about their own sessions
(sessions belonging to a role that they are a member of). In rows about
other sessions, many columns will be null. Note, however, that the
existence of a session and its general properties such as its sessions user
Use has_privs_for_roles for predefined role checks Generally if a role is granted membership to another role with NOINHERIT they must use SET ROLE to access the privileges of that role, however with predefined roles the membership and privilege is conflated. Fix that by replacing is_member_of_role with has_privs_for_role for predefined roles. Patch does not remove is_member_of_role from acl.h, but it does add a warning not to use that function for privilege checking. Not backpatched based on hackers list discussion. Author: Joshua Brindle Reviewed-by: Stephen Frost, Nathan Bossart, Joe Conway Discussion: https://postgr.es/m/flat/CAGB+Vh4Zv_TvKt2tv3QNS6tUM_F_9icmuj0zjywwcgVi4PAhFA@mail.gmail.com
2022-03-28 21:10:04 +02:00
and database are visible to all users. Superusers and roles with privileges of
doc: Add security information about pg_stat_activity Add a basic note that some columns in pg_stat_activity and related views are not visible to all users. Discussion: https://www.postgresql.org/message-id/3018acd9-e5d8-1e85-5ed7-47276cd77569%402ndquadrant.com
2019-02-21 19:49:27 +01:00
built-in role <literal>pg_read_all_stats</literal> (see also <xref
Rename Default Roles to Predefined Roles The term 'default roles' wasn't quite apt as these roles aren't able to be modified or removed after installation, so rename them to be 'Predefined Roles' instead, adding an entry into the newly added Obsolete Appendix to help users of current releases find the new documentation. Bruce Momjian and Stephen Frost Discussion: https://postgr.es/m/157742545062.1149.11052653770497832538%40wrigleys.postgresql.org and https://www.postgresql.org/message-id/20201120211304.GG16415@tamriel.snowman.net
2021-04-01 21:32:06 +02:00
linkend="predefined-roles"/>) can see all the information about all sessions.
doc: Add security information about pg_stat_activity Add a basic note that some columns in pg_stat_activity and related views are not visible to all users. Discussion: https://www.postgresql.org/message-id/3018acd9-e5d8-1e85-5ed7-47276cd77569%402ndquadrant.com
2019-02-21 19:49:27 +01:00
</para>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<table id="monitoring-stats-dynamic-views-table">
<title>Dynamic Statistics Views</title>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<tgroup cols="2">
<thead>
<row>
<entry>View Name</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
<entry>
<structname>pg_stat_activity</structname>
<indexterm><primary>pg_stat_activity</primary></indexterm>
</entry>
<entry>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
One row per server process, showing information related to
the current activity of that process, such as state and current query.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-activity-view">
<structname>pg_stat_activity</structname></link> for details.
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_replication</structname><indexterm><primary>pg_stat_replication</primary></indexterm></entry>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<entry>One row per WAL sender process, showing statistics about
replication to that sender's connected standby server.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-replication-view">
<structname>pg_stat_replication</structname></link> for details.
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
</entry>
</row>
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_wal_receiver</structname><indexterm><primary>pg_stat_wal_receiver</primary></indexterm></entry>
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
<entry>Only one row, showing statistics about the WAL receiver from
that receiver's connected server.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-wal-receiver-view">
<structname>pg_stat_wal_receiver</structname></link> for details.
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
</entry>
</row>
Prefetch data referenced by the WAL, take II. Introduce a new GUC recovery_prefetch. When enabled, look ahead in the WAL and try to initiate asynchronous reading of referenced data blocks that are not yet cached in our buffer pool. For now, this is done with posix_fadvise(), which has several caveats. Since not all OSes have that system call, "try" is provided so that it can be enabled where available. Better mechanisms for asynchronous I/O are possible in later work. Set to "try" for now for test coverage. Default setting to be finalized before release. The GUC wal_decode_buffer_size limits the distance we can look ahead in bytes of decoded data. The existing GUC maintenance_io_concurrency is used to limit the number of concurrent I/Os allowed, based on pessimistic heuristics used to infer that I/Os have begun and completed. We'll also not look more than maintenance_io_concurrency * 4 block references ahead. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (earlier version) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (earlier version) Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (earlier version) Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com> (earlier version) Tested-by: Dmitry Dolgov <9erthalion6@gmail.com> (earlier version) Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com
2022-04-07 09:28:40 +02:00
<row>
<entry><structname>pg_stat_recovery_prefetch</structname><indexterm><primary>pg_stat_recovery_prefetch</primary></indexterm></entry>
<entry>Only one row, showing statistics about blocks prefetched during recovery.
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
See <link linkend="monitoring-pg-stat-recovery-prefetch">
<structname>pg_stat_recovery_prefetch</structname></link> for details.
Prefetch data referenced by the WAL, take II. Introduce a new GUC recovery_prefetch. When enabled, look ahead in the WAL and try to initiate asynchronous reading of referenced data blocks that are not yet cached in our buffer pool. For now, this is done with posix_fadvise(), which has several caveats. Since not all OSes have that system call, "try" is provided so that it can be enabled where available. Better mechanisms for asynchronous I/O are possible in later work. Set to "try" for now for test coverage. Default setting to be finalized before release. The GUC wal_decode_buffer_size limits the distance we can look ahead in bytes of decoded data. The existing GUC maintenance_io_concurrency is used to limit the number of concurrent I/Os allowed, based on pessimistic heuristics used to infer that I/Os have begun and completed. We'll also not look more than maintenance_io_concurrency * 4 block references ahead. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (earlier version) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (earlier version) Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (earlier version) Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com> (earlier version) Tested-by: Dmitry Dolgov <9erthalion6@gmail.com> (earlier version) Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com
2022-04-07 09:28:40 +02:00
</entry>
</row>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_subscription</structname><indexterm><primary>pg_stat_subscription</primary></indexterm></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<entry>At least one row per subscription, showing information about
the subscription workers.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-subscription">
<structname>pg_stat_subscription</structname></link> for details.
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</entry>
</row>
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_ssl</structname><indexterm><primary>pg_stat_ssl</primary></indexterm></entry>
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
<entry>One row per connection (regular and replication), showing information about
SSL used on this connection.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-ssl-view">
<structname>pg_stat_ssl</structname></link> for details.
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
</entry>
</row>
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
<row>
<entry><structname>pg_stat_gssapi</structname><indexterm><primary>pg_stat_gssapi</primary></indexterm></entry>
<entry>One row per connection (regular and replication), showing information about
GSSAPI authentication and encryption used on this connection.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-gssapi-view">
<structname>pg_stat_gssapi</structname></link> for details.
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
</entry>
</row>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<row>
<entry><structname>pg_stat_progress_analyze</structname><indexterm><primary>pg_stat_progress_analyze</primary></indexterm></entry>
<entry>One row for each backend (including autovacuum worker processes) running
<command>ANALYZE</command>, showing current progress.
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
See <xref linkend="analyze-progress-reporting"/>.
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
</entry>
</row>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
<entry><structname>pg_stat_progress_create_index</structname><indexterm><primary>pg_stat_progress_create_index</primary></indexterm></entry>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<entry>One row for each backend running <command>CREATE INDEX</command> or <command>REINDEX</command>, showing
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
current progress.
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
See <xref linkend="create-index-progress-reporting"/>.
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</entry>
</row>
Move pg_stat_progress_vacuum to the table of Dynamic Statistics Views in doc. Previously the description about pg_stat_progress_vacuum was in the table of "Collected Statistics Views" in the doc. But since it repors dynamic information, i.e., the current progress of VACUUM, its description should be in the table of "Dynamic Statistics Views". Back-patch to 9.6 where pg_stat_progress_vacuum was added. Author: Amit Langote Discussion: http://postgr.es/m/7ab51b59-8d4d-6193-c60a-b75f222efb12@lab.ntt.co.jp
2017-04-13 05:09:14 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_progress_vacuum</structname><indexterm><primary>pg_stat_progress_vacuum</primary></indexterm></entry>
Move pg_stat_progress_vacuum to the table of Dynamic Statistics Views in doc. Previously the description about pg_stat_progress_vacuum was in the table of "Collected Statistics Views" in the doc. But since it repors dynamic information, i.e., the current progress of VACUUM, its description should be in the table of "Dynamic Statistics Views". Back-patch to 9.6 where pg_stat_progress_vacuum was added. Author: Amit Langote Discussion: http://postgr.es/m/7ab51b59-8d4d-6193-c60a-b75f222efb12@lab.ntt.co.jp
2017-04-13 05:09:14 +02:00
<entry>One row for each backend (including autovacuum worker processes) running
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<command>VACUUM</command>, showing current progress.
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
See <xref linkend="vacuum-progress-reporting"/>.
Move pg_stat_progress_vacuum to the table of Dynamic Statistics Views in doc. Previously the description about pg_stat_progress_vacuum was in the table of "Collected Statistics Views" in the doc. But since it repors dynamic information, i.e., the current progress of VACUUM, its description should be in the table of "Dynamic Statistics Views". Back-patch to 9.6 where pg_stat_progress_vacuum was added. Author: Amit Langote Discussion: http://postgr.es/m/7ab51b59-8d4d-6193-c60a-b75f222efb12@lab.ntt.co.jp
2017-04-13 05:09:14 +02:00
</entry>
</row>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<row>
<entry><structname>pg_stat_progress_cluster</structname><indexterm><primary>pg_stat_progress_cluster</primary></indexterm></entry>
<entry>One row for each backend running
<command>CLUSTER</command> or <command>VACUUM FULL</command>, showing current progress.
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
See <xref linkend="cluster-progress-reporting"/>.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</entry>
</row>
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
<row>
<entry><structname>pg_stat_progress_basebackup</structname><indexterm><primary>pg_stat_progress_basebackup</primary></indexterm></entry>
<entry>One row for each WAL sender process streaming a base backup,
showing current progress.
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
See <xref linkend="basebackup-progress-reporting"/>.
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
</entry>
</row>
Report progress of COPY commands This commit introduces a view pg_stat_progress_copy, reporting progress of COPY commands. This allows rough estimates how far a running COPY progressed, with the caveat that the total number of bytes may not be available in some cases (e.g. when the input comes from the client). Author: Josef Šimánek Reviewed-by: Fujii Masao, Bharath Rupireddy, Vignesh C, Matthias van de Meent Discussion: https://postgr.es/m/CAFp7QwqMGEi4OyyaLEK9DR0+E+oK3UtA4bEjDVCa4bNkwUY2PQ@mail.gmail.com Discussion: https://postgr.es/m/CAFp7Qwr6_FmRM6pCO0x_a0mymOfX_Gg+FEKet4XaTGSW=LitKQ@mail.gmail.com
2021-01-06 21:46:26 +01:00
<row>
<entry><structname>pg_stat_progress_copy</structname><indexterm><primary>pg_stat_progress_copy</primary></indexterm></entry>
<entry>One row for each backend running <command>COPY</command>, showing current progress.
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
See <xref linkend="copy-progress-reporting"/>.
Report progress of COPY commands This commit introduces a view pg_stat_progress_copy, reporting progress of COPY commands. This allows rough estimates how far a running COPY progressed, with the caveat that the total number of bytes may not be available in some cases (e.g. when the input comes from the client). Author: Josef Šimánek Reviewed-by: Fujii Masao, Bharath Rupireddy, Vignesh C, Matthias van de Meent Discussion: https://postgr.es/m/CAFp7QwqMGEi4OyyaLEK9DR0+E+oK3UtA4bEjDVCa4bNkwUY2PQ@mail.gmail.com Discussion: https://postgr.es/m/CAFp7Qwr6_FmRM6pCO0x_a0mymOfX_Gg+FEKet4XaTGSW=LitKQ@mail.gmail.com
2021-01-06 21:46:26 +01:00
</entry>
</row>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
</tbody>
</tgroup>
</table>
<table id="monitoring-stats-views-table">
<title>Collected Statistics Views</title>
<tgroup cols="2">
<thead>
<row>
<entry>View Name</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
doc: Re-order Table 28.2 "Collected Statistics Views" Make the order more sensible and repeatable. Comments have been added to guide future additions. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2023-01-02 08:45:17 +01:00
<!-- everything related to global objects, alphabetically -->
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_archiver</structname><indexterm><primary>pg_stat_archiver</primary></indexterm></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<entry>One row only, showing statistics about the
WAL archiver process's activity. See
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<link linkend="monitoring-pg-stat-archiver-view">
<structname>pg_stat_archiver</structname></link> for details.
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</entry>
</row>
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_bgwriter</structname><indexterm><primary>pg_stat_bgwriter</primary></indexterm></entry>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
<entry>One row only, showing statistics about the
background writer process's activity. See
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<link linkend="monitoring-pg-stat-bgwriter-view">
<structname>pg_stat_bgwriter</structname></link> for details.
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
</entry>
</row>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<row>
<entry><structname>pg_stat_checkpointer</structname><indexterm><primary>pg_stat_checkpointer</primary></indexterm></entry>
<entry>One row only, showing statistics about the
checkpointer process's activity. See
<link linkend="monitoring-pg-stat-checkpointer-view">
<structname>pg_stat_checkpointer</structname></link> for details.
</entry>
</row>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_database</structname><indexterm><primary>pg_stat_database</primary></indexterm></entry>
Fix some typos and correct wording in the monitoring docs patch Thom Brown
2012-02-25 16:33:57 +01:00
<entry>One row per database, showing database-wide statistics. See
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<link linkend="monitoring-pg-stat-database-view">
<structname>pg_stat_database</structname></link> for details.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</entry>
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
</row>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_database_conflicts</structname><indexterm><primary>pg_stat_database_conflicts</primary></indexterm></entry>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<entry>
One row per database, showing database-wide statistics about
query cancels due to conflict with recovery on standby servers.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-database-conflicts-view">
<structname>pg_stat_database_conflicts</structname></link> for details.
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
</entry>
</row>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<row>
<entry><structname>pg_stat_io</structname><indexterm><primary>pg_stat_io</primary></indexterm></entry>
<entry>
One row for each combination of backend type, context, and target object
containing cluster-wide I/O statistics.
See <link linkend="monitoring-pg-stat-io-view">
<structname>pg_stat_io</structname></link> for details.
</entry>
</row>
doc: Re-order Table 28.2 "Collected Statistics Views" Make the order more sensible and repeatable. Comments have been added to guide future additions. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2023-01-02 08:45:17 +01:00
<row>
<entry><structname>pg_stat_replication_slots</structname><indexterm><primary>pg_stat_replication_slots</primary></indexterm></entry>
<entry>One row per replication slot, showing statistics about the
replication slot's usage. See
<link linkend="monitoring-pg-stat-replication-slots-view">
<structname>pg_stat_replication_slots</structname></link> for details.
</entry>
</row>
<row>
<entry><structname>pg_stat_slru</structname><indexterm><primary>pg_stat_slru</primary></indexterm></entry>
<entry>One row per SLRU, showing statistics of operations. See
<link linkend="monitoring-pg-stat-slru-view">
<structname>pg_stat_slru</structname></link> for details.
</entry>
</row>
<row>
<entry><structname>pg_stat_subscription_stats</structname><indexterm><primary>pg_stat_subscription_stats</primary></indexterm></entry>
<entry>One row per subscription, showing statistics about errors.
See <link linkend="monitoring-pg-stat-subscription-stats">
<structname>pg_stat_subscription_stats</structname></link> for details.
</entry>
</row>
<row>
<entry><structname>pg_stat_wal</structname><indexterm><primary>pg_stat_wal</primary></indexterm></entry>
<entry>One row only, showing statistics about WAL activity. See
<link linkend="monitoring-pg-stat-wal-view">
<structname>pg_stat_wal</structname></link> for details.
</entry>
</row>
<!-- all "stat" for schema objects, by "importance" -->
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_all_tables</structname><indexterm><primary>pg_stat_all_tables</primary></indexterm></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<entry>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
One row for each table in the current database, showing statistics
about accesses to that specific table.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-all-tables-view">
<structname>pg_stat_all_tables</structname></link> for details.
Change pg_stat_all_tables and sister views to put the recently-added vacuum/analyze timestamp columns at the end, rather than at a random spot in the middle as in the original patch. This was deemed more usable as well as less likely to break existing application code. initdb forced accordingly. In passing, remove former kluge for initializing pg_stat_file()'s pg_proc entry --- bootstrap mode was fixed recently so that this can be done without any hacks, but I overlooked this usage.
2006-11-24 22:18:42 +01:00
</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_sys_tables</structname><indexterm><primary>pg_stat_sys_tables</primary></indexterm></entry>
<entry>Same as <structname>pg_stat_all_tables</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
system tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_user_tables</structname><indexterm><primary>pg_stat_user_tables</primary></indexterm></entry>
<entry>Same as <structname>pg_stat_all_tables</structname>, except that only user
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_xact_all_tables</structname><indexterm><primary>pg_stat_xact_all_tables</primary></indexterm></entry>
<entry>Similar to <structname>pg_stat_all_tables</structname>, but counts actions
taken so far within the current transaction (which are <emphasis>not</emphasis>
yet included in <structname>pg_stat_all_tables</structname> and related views).
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
The columns for numbers of live and dead rows and vacuum and
analyze actions are not present in this view.</entry>
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_xact_sys_tables</structname><indexterm><primary>pg_stat_xact_sys_tables</primary></indexterm></entry>
<entry>Same as <structname>pg_stat_xact_all_tables</structname>, except that only
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
system tables are shown.</entry>
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_xact_user_tables</structname><indexterm><primary>pg_stat_xact_user_tables</primary></indexterm></entry>
<entry>Same as <structname>pg_stat_xact_all_tables</structname>, except that only
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
user tables are shown.</entry>
</row>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_all_indexes</structname><indexterm><primary>pg_stat_all_indexes</primary></indexterm></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<entry>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
One row for each index in the current database, showing statistics
about accesses to that specific index.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-stat-all-indexes-view">
<structname>pg_stat_all_indexes</structname></link> for details.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</entry>
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_sys_indexes</structname><indexterm><primary>pg_stat_sys_indexes</primary></indexterm></entry>
<entry>Same as <structname>pg_stat_all_indexes</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
indexes on system tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_stat_user_indexes</structname><indexterm><primary>pg_stat_user_indexes</primary></indexterm></entry>
<entry>Same as <structname>pg_stat_all_indexes</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
indexes on user tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
doc: Re-order Table 28.2 "Collected Statistics Views" Make the order more sensible and repeatable. Comments have been added to guide future additions. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2023-01-02 08:45:17 +01:00
<row>
<entry><structname>pg_stat_user_functions</structname><indexterm><primary>pg_stat_user_functions</primary></indexterm></entry>
<entry>
One row for each tracked function, showing statistics
about executions of that function. See
<link linkend="monitoring-pg-stat-user-functions-view">
<structname>pg_stat_user_functions</structname></link> for details.
</entry>
</row>
<row>
<entry><structname>pg_stat_xact_user_functions</structname><indexterm><primary>pg_stat_xact_user_functions</primary></indexterm></entry>
<entry>Similar to <structname>pg_stat_user_functions</structname>, but counts only
calls during the current transaction (which are <emphasis>not</emphasis>
yet included in <structname>pg_stat_user_functions</structname>).</entry>
</row>
<!-- all "statio" for schema objects, by "importance" -->
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_all_tables</structname><indexterm><primary>pg_statio_all_tables</primary></indexterm></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<entry>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
One row for each table in the current database, showing statistics
about I/O on that specific table.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-statio-all-tables-view">
<structname>pg_statio_all_tables</structname></link> for details.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</entry>
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_sys_tables</structname><indexterm><primary>pg_statio_sys_tables</primary></indexterm></entry>
<entry>Same as <structname>pg_statio_all_tables</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
system tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_user_tables</structname><indexterm><primary>pg_statio_user_tables</primary></indexterm></entry>
<entry>Same as <structname>pg_statio_all_tables</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
user tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_all_indexes</structname><indexterm><primary>pg_statio_all_indexes</primary></indexterm></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<entry>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
One row for each index in the current database,
showing statistics about I/O on that specific index.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-statio-all-indexes-view">
<structname>pg_statio_all_indexes</structname></link> for details.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</entry>
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_sys_indexes</structname><indexterm><primary>pg_statio_sys_indexes</primary></indexterm></entry>
<entry>Same as <structname>pg_statio_all_indexes</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
indexes on system tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_user_indexes</structname><indexterm><primary>pg_statio_user_indexes</primary></indexterm></entry>
<entry>Same as <structname>pg_statio_all_indexes</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
indexes on user tables are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_all_sequences</structname><indexterm><primary>pg_statio_all_sequences</primary></indexterm></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<entry>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
One row for each sequence in the current database,
showing statistics about I/O on that specific sequence.
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
See <link linkend="monitoring-pg-statio-all-sequences-view">
<structname>pg_statio_all_sequences</structname></link> for details.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_sys_sequences</structname><indexterm><primary>pg_statio_sys_sequences</primary></indexterm></entry>
<entry>Same as <structname>pg_statio_all_sequences</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
system sequences are shown. (Presently, no system sequences are defined,
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
so this view is always empty.)</entry>
</row>
<row>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<entry><structname>pg_statio_user_sequences</structname><indexterm><primary>pg_statio_user_sequences</primary></indexterm></entry>
<entry>Same as <structname>pg_statio_all_sequences</structname>, except that only
Revise pgstats stuff to fix the problems with not counting accesses generated by bitmap index scans. Along the way, simplify and speed up the code for counting sequential and index scans; it was both confusing and inefficient to be taking care of that in the per-tuple loops, IMHO. initdb forced because of internal changes in pg_stat view definitions.
2005-10-06 04:29:23 +02:00
user sequences are shown.</entry>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</row>
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</tbody>
</tgroup>
</table>
<para>
The per-index statistics are particularly useful to determine which
indexes are being used and how effective they are.
</para>
<para>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
The <structname>pg_stat_io</structname> and
<structname>pg_statio_</structname> set of views are useful for determining
the effectiveness of the buffer cache. They can be used to calculate a cache
hit ratio. Note that while <productname>PostgreSQL</productname>'s I/O
statistics capture most instances in which the kernel was invoked in order
to perform I/O, they do not differentiate between data which had to be
fetched from disk and that which already resided in the kernel page cache.
Users are advised to use the <productname>PostgreSQL</productname>
statistics views in combination with operating system utilities for a more
complete picture of their database's I/O performance.
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-activity-view">
<title><structname>pg_stat_activity</structname></title>
<indexterm>
<primary>pg_stat_activity</primary>
</indexterm>
<para>
The <structname>pg_stat_activity</structname> view will have one row
per server process, showing information related to
the current activity of that process.
</para>
Merge the list of statistics functions into the view documentation Most people won't read them individually anyway, it's an easy way to find them, and it's a lot of duplicated information if they are kept in two different places.
2012-02-25 15:21:04 +01:00
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
<table id="pg-stat-activity-view" xreflabel="pg_stat_activity">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_stat_activity</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database this backend is connected to
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of the database this backend is connected to
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of this backend
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>leader_pid</structfield> <type>integer</type>
</para>
<para>
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
Process ID of the parallel group leader if this process is a parallel
query worker, or process ID of the leader apply worker if this process
is a parallel apply worker. <literal>NULL</literal> indicates that this
process is a parallel group leader or leader apply worker, or does not
participate in any parallel operation.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usesysid</structfield> <type>oid</type>
</para>
<para>
OID of the user logged into this backend
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usename</structfield> <type>name</type>
</para>
<para>
Name of the user logged into this backend
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>application_name</structfield> <type>text</type>
</para>
<para>
Name of the application that is connected
to this backend
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_addr</structfield> <type>inet</type>
</para>
<para>
IP address of the client connected to this backend.
If this field is null, it indicates either that the client is
connected via a Unix socket on the server machine or that this is an
internal process such as autovacuum.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_hostname</structfield> <type>text</type>
</para>
<para>
Host name of the connected client, as reported by a
reverse DNS lookup of <structfield>client_addr</structfield>. This field will
only be non-null for IP connections, and only when <xref linkend="guc-log-hostname"/> is enabled.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_port</structfield> <type>integer</type>
</para>
<para>
TCP port number that the client is using for communication
with this backend, or <literal>-1</literal> if a Unix socket is used.
If this field is null, it indicates that this is an internal server process.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backend_start</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time when this process was started. For client backends,
this is the time the client connected to the server.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>xact_start</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time when this process' current transaction was started, or null
if no transaction is active. If the current
query is the first of its transaction, this column is equal to the
<structfield>query_start</structfield> column.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>query_start</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time when the currently active query was started, or if
<structfield>state</structfield> is not <literal>active</literal>, when the last query
was started
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>state_change</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time when the <structfield>state</structfield> was last changed
</para></entry>
</row>
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wait_event_type</structfield> <type>text</type>
</para>
<para>
The type of event for which the backend is waiting, if any;
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
otherwise NULL. See <xref linkend="wait-event-table"/>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wait_event</structfield> <type>text</type>
</para>
<para>
Wait event name if backend is currently waiting, otherwise NULL.
See <xref linkend="wait-event-activity-table"/> through
<xref linkend="wait-event-timeout-table"/>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>state</structfield> <type>text</type>
</para>
<para>
Current overall state of this backend.
Possible values are:
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
<itemizedlist>
<listitem>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<para>
<literal>active</literal>: The backend is executing a query.
Extend framework from commit 53be0b1ad to report latch waits. WaitLatch, WaitLatchOrSocket, and WaitEventSetWait now taken an additional wait_event_info parameter; legal values are defined in pgstat.h. This makes it possible to uniquely identify every point in the core code where we are waiting for a latch; extensions can pass WAIT_EXTENSION. Because latches were the major wait primitive not previously covered by this patch, it is now possible to see information in pg_stat_activity on a large number of important wait events not previously addressed, such as ClientRead, ClientWrite, and SyncRep. Unfortunately, many of the wait events added by this patch will fail to appear in pg_stat_activity because they're only used in background processes which don't currently appear in pg_stat_activity. We should fix this either by creating a separate view for such information, or else by deciding to include them in pg_stat_activity after all. Michael Paquier and Robert Haas, reviewed by Alexander Korotkov and Thomas Munro.
2016-10-04 16:50:13 +02:00
</para>
</listitem>
<listitem>
<para>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<literal>idle</literal>: The backend is waiting for a new client command.
Extend framework from commit 53be0b1ad to report latch waits. WaitLatch, WaitLatchOrSocket, and WaitEventSetWait now taken an additional wait_event_info parameter; legal values are defined in pgstat.h. This makes it possible to uniquely identify every point in the core code where we are waiting for a latch; extensions can pass WAIT_EXTENSION. Because latches were the major wait primitive not previously covered by this patch, it is now possible to see information in pg_stat_activity on a large number of important wait events not previously addressed, such as ClientRead, ClientWrite, and SyncRep. Unfortunately, many of the wait events added by this patch will fail to appear in pg_stat_activity because they're only used in background processes which don't currently appear in pg_stat_activity. We should fix this either by creating a separate view for such information, or else by deciding to include them in pg_stat_activity after all. Michael Paquier and Robert Haas, reviewed by Alexander Korotkov and Thomas Munro.
2016-10-04 16:50:13 +02:00
</para>
</listitem>
<listitem>
<para>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<literal>idle in transaction</literal>: The backend is in a transaction,
but is not currently executing a query.
Extend framework from commit 53be0b1ad to report latch waits. WaitLatch, WaitLatchOrSocket, and WaitEventSetWait now taken an additional wait_event_info parameter; legal values are defined in pgstat.h. This makes it possible to uniquely identify every point in the core code where we are waiting for a latch; extensions can pass WAIT_EXTENSION. Because latches were the major wait primitive not previously covered by this patch, it is now possible to see information in pg_stat_activity on a large number of important wait events not previously addressed, such as ClientRead, ClientWrite, and SyncRep. Unfortunately, many of the wait events added by this patch will fail to appear in pg_stat_activity because they're only used in background processes which don't currently appear in pg_stat_activity. We should fix this either by creating a separate view for such information, or else by deciding to include them in pg_stat_activity after all. Michael Paquier and Robert Haas, reviewed by Alexander Korotkov and Thomas Munro.
2016-10-04 16:50:13 +02:00
</para>
</listitem>
<listitem>
<para>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<literal>idle in transaction (aborted)</literal>: This state is similar to
<literal>idle in transaction</literal>, except one of the statements in
the transaction caused an error.
Extend framework from commit 53be0b1ad to report latch waits. WaitLatch, WaitLatchOrSocket, and WaitEventSetWait now taken an additional wait_event_info parameter; legal values are defined in pgstat.h. This makes it possible to uniquely identify every point in the core code where we are waiting for a latch; extensions can pass WAIT_EXTENSION. Because latches were the major wait primitive not previously covered by this patch, it is now possible to see information in pg_stat_activity on a large number of important wait events not previously addressed, such as ClientRead, ClientWrite, and SyncRep. Unfortunately, many of the wait events added by this patch will fail to appear in pg_stat_activity because they're only used in background processes which don't currently appear in pg_stat_activity. We should fix this either by creating a separate view for such information, or else by deciding to include them in pg_stat_activity after all. Michael Paquier and Robert Haas, reviewed by Alexander Korotkov and Thomas Munro.
2016-10-04 16:50:13 +02:00
</para>
</listitem>
<listitem>
<para>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<literal>fastpath function call</literal>: The backend is executing a
fast-path function.
Extend framework from commit 53be0b1ad to report latch waits. WaitLatch, WaitLatchOrSocket, and WaitEventSetWait now taken an additional wait_event_info parameter; legal values are defined in pgstat.h. This makes it possible to uniquely identify every point in the core code where we are waiting for a latch; extensions can pass WAIT_EXTENSION. Because latches were the major wait primitive not previously covered by this patch, it is now possible to see information in pg_stat_activity on a large number of important wait events not previously addressed, such as ClientRead, ClientWrite, and SyncRep. Unfortunately, many of the wait events added by this patch will fail to appear in pg_stat_activity because they're only used in background processes which don't currently appear in pg_stat_activity. We should fix this either by creating a separate view for such information, or else by deciding to include them in pg_stat_activity after all. Michael Paquier and Robert Haas, reviewed by Alexander Korotkov and Thomas Munro.
2016-10-04 16:50:13 +02:00
</para>
</listitem>
Create and use wait events for read, write, and fsync operations. Previous commits, notably 53be0b1add7064ca5db3cd884302dfc3268d884e and 6f3bd98ebfc008cbd676da777bb0b2376c4c4bfa, made it possible to see from pg_stat_activity when a backend was stuck waiting for another backend, but it's also fairly common for a backend to be stuck waiting for an I/O. Add wait events for those operations, too. Rushabh Lathia, with further hacking by me. Reviewed and tested by Michael Paquier, Amit Kapila, Rajkumar Raghuwanshi, and Rahila Syed. Discussion: http://postgr.es/m/CAGPqQf0LsYHXREPAZqYGVkDqHSyjf=KsD=k0GTVPAuzyThh-VQ@mail.gmail.com
2017-03-18 12:43:01 +01:00
<listitem>
<para>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<literal>disabled</literal>: This state is reported if <xref linkend="guc-track-activities"/> is disabled in this backend.
Create and use wait events for read, write, and fsync operations. Previous commits, notably 53be0b1add7064ca5db3cd884302dfc3268d884e and 6f3bd98ebfc008cbd676da777bb0b2376c4c4bfa, made it possible to see from pg_stat_activity when a backend was stuck waiting for another backend, but it's also fairly common for a backend to be stuck waiting for an I/O. Add wait events for those operations, too. Rushabh Lathia, with further hacking by me. Reviewed and tested by Michael Paquier, Amit Kapila, Rajkumar Raghuwanshi, and Rahila Syed. Discussion: http://postgr.es/m/CAGPqQf0LsYHXREPAZqYGVkDqHSyjf=KsD=k0GTVPAuzyThh-VQ@mail.gmail.com
2017-03-18 12:43:01 +01:00
</para>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</listitem>
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
</itemizedlist>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backend_xid</structfield> <type>xid</type>
</para>
<para>
doc: add transaction processing chapter with internals info This also adds references to this new chapter at relevant sections of our documentation. Previously much of these internal details were exposed to users, but not explained. This also updates RELEASE SAVEPOINT. Discussion: https://postgr.es/m/CANbhV-E_iy9fmrErxrCh8TZTyenpfo72Hf_XD2HLDppva4dUNA@mail.gmail.com Author: Simon Riggs, Laurenz Albe Reviewed-by: Bruce Momjian Backpatch-through: 11
2022-11-30 02:49:52 +01:00
Top-level transaction identifier of this backend, if any; see
<xref linkend="transaction-id"/>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backend_xmin</structfield> <type>xid</type>
</para>
<para>
The current backend's <literal>xmin</literal> horizon.
</para></entry>
</row>
Make use of in-core query id added by commit 5fd9dfa5f5 Use the in-core query id computation for pg_stat_activity, log_line_prefix, and EXPLAIN VERBOSE. Similar to other fields in pg_stat_activity, only the queryid from the top level statements are exposed, and if the backends status isn't active then the queryid from the last executed statements is displayed. Add a %Q placeholder to include the queryid in log_line_prefix, which will also only expose top level statements. For EXPLAIN VERBOSE, if a query identifier has been computed, either by enabling compute_query_id or using a third-party module, display it. Bump catalog version. Discussion: https://postgr.es/m/20210407125726.tkvjdbw76hxnpwfi@nol Author: Julien Rouhaud Reviewed-by: Alvaro Herrera, Nitin Jadhav, Zhihong Yu
2021-04-07 20:03:56 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
adjust query id feature to use pg_stat_activity.query_id Previously, it was pg_stat_activity.queryid to match the pg_stat_statements queryid column. This is an adjustment to patch 4f0b0966c8. This also adjusts some of the internal function calls to match. Catversion bumped. Reported-by: Álvaro Herrera, Julien Rouhaud Discussion: https://postgr.es/m/20210408032704.GA7498@alvherre.pgsql
2021-04-20 18:22:26 +02:00
<structfield>query_id</structfield> <type>bigint</type>
Make use of in-core query id added by commit 5fd9dfa5f5 Use the in-core query id computation for pg_stat_activity, log_line_prefix, and EXPLAIN VERBOSE. Similar to other fields in pg_stat_activity, only the queryid from the top level statements are exposed, and if the backends status isn't active then the queryid from the last executed statements is displayed. Add a %Q placeholder to include the queryid in log_line_prefix, which will also only expose top level statements. For EXPLAIN VERBOSE, if a query identifier has been computed, either by enabling compute_query_id or using a third-party module, display it. Bump catalog version. Discussion: https://postgr.es/m/20210407125726.tkvjdbw76hxnpwfi@nol Author: Julien Rouhaud Reviewed-by: Alvaro Herrera, Nitin Jadhav, Zhihong Yu
2021-04-07 20:03:56 +02:00
</para>
<para>
Identifier of this backend's most recent query. If
<structfield>state</structfield> is <literal>active</literal> this
field shows the identifier of the currently executing query. In
all other states, it shows the identifier of last query that was
executed. Query identifiers are not computed by default so this
field will be null unless <xref linkend="guc-compute-query-id"/>
parameter is enabled or a third-party module that computes query
identifiers is configured.
</para></entry>
</row>
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>query</structfield> <type>text</type>
</para>
<para>
Text of this backend's most recent query. If
<structfield>state</structfield> is <literal>active</literal> this field shows the
currently executing query. In all other states, it shows the last query
that was executed. By default the query text is truncated at 1024
doc: Correct the description about the length of pg_stat_activity.query. pg_stat_activity.query text is truncated at 1024 bytes. But previously the document described that it's truncated at 1024 characters. This was not accurate when considering multibyte characters. Back-patch to v10 where this inaccurate description was added. Author: Atsushi Torikoshi Reviewed-by: Daniel Gustafsson, Fujii Masao Discussion: https://postgr.es/m/cd5b49a5a14e887542f5f569c1c6bde2@oss.nttdata.com
2020-07-09 06:31:33 +02:00
bytes; this value can be changed via the parameter
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<xref linkend="guc-track-activity-query-size"/>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backend_type</structfield> <type>text</type>
</para>
<para>
Type of current backend. Possible types are
<literal>autovacuum launcher</literal>, <literal>autovacuum worker</literal>,
<literal>logical replication launcher</literal>,
<literal>logical replication worker</literal>,
<literal>parallel worker</literal>, <literal>background writer</literal>,
<literal>client backend</literal>, <literal>checkpointer</literal>,
doc: Add missing backend_type to pg_stat_activity Commit 0c679464a8 added the missing backendDesc for B_STANDALONE_BACKEND but missed updating the list of backend types in the documentation. Fix by adding it to the list. Author: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com> Discussion: https://postgr.es/m/DM4PR84MB1734ECEA02BCB59564E8FC03EE4A9@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
2023-05-30 10:31:11 +02:00
<literal>archiver</literal>, <literal>standalone backend</literal>,
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<literal>startup</literal>, <literal>walreceiver</literal>,
More documentation updates for incremental backup. Add new terms to glossary. Add a reference to walsummarizer to monitoring.sgml. Matthias van de Meent and Robert Haas Discussion: http://postgr.es/m/CAEze2WjhdVCqEe_qqEok3NA6DwUdOGSBjAxzmYdAqiaaH1uRcg@mail.gmail.com
2024-01-18 15:25:28 +01:00
<literal>walsender</literal>, <literal>walwriter</literal> and
<literal>walsummarizer</literal>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
In addition, background workers registered by extensions may have
additional types.
</para></entry>
</row>
</tbody>
</tgroup>
</table>
<note>
<para>
The <structfield>wait_event</structfield> and <structfield>state</structfield> columns are
independent. If a backend is in the <literal>active</literal> state,
it may or may not be <literal>waiting</literal> on some event. If the state
is <literal>active</literal> and <structfield>wait_event</structfield> is non-null, it
means that a query is being executed, but is being blocked somewhere
in the system.
</para>
</note>
<table id="wait-event-table">
<title>Wait Event Types</title>
<tgroup cols="2">
<thead>
<row>
<entry>Wait Event Type</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>Activity</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry>The server process is idle. This event type indicates a process
waiting for activity in its main processing loop.
<literal>wait_event</literal> will identify the specific wait point;
see <xref linkend="wait-event-activity-table"/>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</entry>
</row>
<row>
<entry><literal>BufferPin</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry>The server process is waiting for exclusive access to
a data buffer. Buffer pin waits can be protracted if
another process holds an open cursor that last read data from the
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
buffer in question. See <xref linkend="wait-event-bufferpin-table"/>.
</entry>
</row>
<row>
<entry><literal>Client</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry>The server process is waiting for activity on a socket
connected to a user application. Thus, the server expects something
to happen that is independent of its internal processes.
<literal>wait_event</literal> will identify the specific wait point;
see <xref linkend="wait-event-client-table"/>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</entry>
</row>
<row>
<entry><literal>Extension</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry>The server process is waiting for some condition defined by an
extension module.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
See <xref linkend="wait-event-extension-table"/>.
</entry>
</row>
<row>
<entry><literal>IO</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry>The server process is waiting for an I/O operation to complete.
<literal>wait_event</literal> will identify the specific wait point;
see <xref linkend="wait-event-io-table"/>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</entry>
</row>
<row>
<entry><literal>IPC</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry>The server process is waiting for some interaction with
another server process. <literal>wait_event</literal> will
identify the specific wait point;
see <xref linkend="wait-event-ipc-table"/>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</entry>
</row>
<row>
<entry><literal>Lock</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry>The server process is waiting for a heavyweight lock.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
Heavyweight locks, also known as lock manager locks or simply locks,
primarily protect SQL-visible objects such as tables. However,
they are also used to ensure mutual exclusion for certain internal
operations such as relation extension. <literal>wait_event</literal>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
will identify the type of lock awaited;
see <xref linkend="wait-event-lock-table"/>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</entry>
</row>
<row>
<entry><literal>LWLock</literal></entry>
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
<entry> The server process is waiting for a lightweight lock.
Most such locks protect a particular data structure in shared memory.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
<literal>wait_event</literal> will contain a name identifying the purpose
of the lightweight lock. (Some locks have specific names; others
are part of a group of locks each with a similar purpose.)
See <xref linkend="wait-event-lwlock-table"/>.
</entry>
</row>
<row>
<entry><literal>Timeout</literal></entry>
<entry>The server process is waiting for a timeout
to expire. <literal>wait_event</literal> will identify the specific wait
Change locktype "speculative token" to "spectoken". It's just weird that this name wasn't chosen to look like an identifier. The suspicion that it wasn't thought about too hard is reinforced by the fact that it wasn't documented in the pg_locks view (until I did so, a day or two back). Update, and add a comment reminding future adjusters of this array to fix the docs too. Do some desultory wordsmithing on various entries in the wait events tables. Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us
2020-05-16 03:47:21 +02:00
point; see <xref linkend="wait-event-timeout-table"/>.
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
</entry>
</row>
</tbody>
</tgroup>
</table>
Generate automatically code and documentation related to wait events The documentation and the code is generated automatically from a new file called wait_event_names.txt, formatted in sections dedicated to each wait event class (Timeout, Lock, IO, etc.) with three tab-separated fields: - C symbol in enums - Format in the system views - Description in the docs Using this approach has several advantages, as we have proved to be rather bad in maintaining this area of the tree across the years: - The order of each item in the documentation and the code, which should be alphabetical, has become incorrect multiple times, and the script generating the code and documentation has a few rules to enforce that, making the maintenance a no-brainer. - Some wait events were added to the code, but not documented, so this cannot be missed now. - The order of the tables for each wait event class is enforced in the documentation (the input .txt file does so as well for clarity, though this is not mandatory). - Less code, shaving 1.2k lines from the tree, with 1/3 of the savings coming from the code, the rest from the documentation. The wait event types "Lock" and "LWLock" still have their own code path for their code, hence only the documentation is created for them. These classes are listed with a special marker called WAIT_EVENT_DOCONLY in the input file. Adding a new wait event now requires only an update of wait_event_names.txt, with "Lock" and "LWLock" treated as exceptions. This commit has been tested with configure/Makefile, the CI and VPATH build. clean, distclean and maintainer-clean were working fine. Author: Bertrand Drouvot, Michael Paquier Discussion: https://postgr.es/m/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9b98@gmail.com
2023-07-05 03:53:11 +02:00
&wait_event_types;
Doc: split up wait_event table. The previous design for this table didn't really work in narrow views, such as PDF output; besides which its reliance on large morerows values made it a pain to maintain (cf ab3e4fbd5, for example). I experimented with a couple of ways to fix it, but the best and simplest is to split it up into a separate table for each event type category. I also rearranged the event ordering to be strictly alphabetical, as nobody would ever be able to find entries otherwise. There is work afoot to revise the set of event names described in this table, but this commit just changes the layout, not the contents. In passing, add a missing entry to pg_locks.locktype, and cross-reference that to the related wait event list. Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us
2020-05-14 05:36:58 +02:00
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
<para>
Add system view pg_wait_events This new view, wrapped around a SRF, shows some information known about wait events, as of: - Name. - Type (Activity, I/O, Extension, etc.). - Description. All the information retrieved comes from wait_event_names.txt, and the description is the same as the documentation with filters applied to remove any XML markups. This view is useful when joined with pg_stat_activity to get the description of a wait event reported. Custom wait events for extensions are included in the view. Original idea by Yves Colin. Author: Bertrand Drouvot Reviewed-by: Kyotaro Horiguchi, Masahiro Ikeda, Tom Lane, Michael Paquier Discussion: https://postgr.es/m/0e2ae164-dc89-03c3-cf7f-de86378053ac@gmail.com
2023-08-20 08:35:02 +02:00
Here are examples of how wait events can be viewed:
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
<programlisting>
SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL;
Remove trailing whitespace from *.sgml files. Historically we've been lax about this, but seeing that we're not lax in C files, there doesn't seem to be a good reason to be so in the documentation. Remove the existing occurrences (mostly though not entirely in copied-n-pasted psql output), and modify .gitattributes so that "git diff --check" will warn about future cases. While at it, add *.pm to the set of extensions .gitattributes knows about, and remove some obsolete entries for files that we don't have in the tree anymore. Per followup discussion of commit 5a892c9b1. Discussion: https://postgr.es/m/E1nfcV1-000kOR-E5@gemulon.postgresql.org
2022-04-20 17:04:28 +02:00
pid | wait_event_type | wait_event
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
------+-----------------+------------
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
2540 | Lock | relation
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
6644 | LWLock | ProcArray
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
(2 rows)
Add system view pg_wait_events This new view, wrapped around a SRF, shows some information known about wait events, as of: - Name. - Type (Activity, I/O, Extension, etc.). - Description. All the information retrieved comes from wait_event_names.txt, and the description is the same as the documentation with filters applied to remove any XML markups. This view is useful when joined with pg_stat_activity to get the description of a wait event reported. Custom wait events for extensions are included in the view. Original idea by Yves Colin. Author: Bertrand Drouvot Reviewed-by: Kyotaro Horiguchi, Masahiro Ikeda, Tom Lane, Michael Paquier Discussion: https://postgr.es/m/0e2ae164-dc89-03c3-cf7f-de86378053ac@gmail.com
2023-08-20 08:35:02 +02:00
</programlisting>
<programlisting>
SELECT a.pid, a.wait_event, w.description
FROM pg_stat_activity a JOIN
pg_wait_events w ON (a.wait_event_type = w.type AND
a.wait_event = w.name)
doc: Improve example query related to pg_wait_events Author: Pavel Luzanov Discussion: https://postgr.es/m/4f79be75-7e30-4817-b0da-4a691ea5427f@postgrespro.ru
2023-10-24 01:40:43 +02:00
WHERE a.wait_event is NOT NULL and a.state = 'active';
Doc: suppress "exceed the available area" warning in PDF build. Allow a line break in example output, as we have done elsewhere. Overlength output was added in commit 1e68e43d3. While here, adjust some shaky grammar in an adjacent note (from a different commit, c9af05465). Per buildfarm.
2023-10-03 20:13:53 +02:00
-[ RECORD 1 ]------------------------------------------------------&zwsp;------------
Add system view pg_wait_events This new view, wrapped around a SRF, shows some information known about wait events, as of: - Name. - Type (Activity, I/O, Extension, etc.). - Description. All the information retrieved comes from wait_event_names.txt, and the description is the same as the documentation with filters applied to remove any XML markups. This view is useful when joined with pg_stat_activity to get the description of a wait event reported. Custom wait events for extensions are included in the view. Original idea by Yves Colin. Author: Bertrand Drouvot Reviewed-by: Kyotaro Horiguchi, Masahiro Ikeda, Tom Lane, Michael Paquier Discussion: https://postgr.es/m/0e2ae164-dc89-03c3-cf7f-de86378053ac@gmail.com
2023-08-20 08:35:02 +02:00
pid | 686674
wait_event | WALInitSync
description | Waiting for a newly initialized WAL file to reach durable storage
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
</programlisting>
</para>
First-draft release notes for Postgres 9.6. These are just of beta quality, but we're only at beta ... the section about parallel query, in particular, could doubtless use more work.
2016-05-05 19:27:59 +02:00
Generate automatically code and documentation related to wait events The documentation and the code is generated automatically from a new file called wait_event_names.txt, formatted in sections dedicated to each wait event class (Timeout, Lock, IO, etc.) with three tab-separated fields: - C symbol in enums - Format in the system views - Description in the docs Using this approach has several advantages, as we have proved to be rather bad in maintaining this area of the tree across the years: - The order of each item in the documentation and the code, which should be alphabetical, has become incorrect multiple times, and the script generating the code and documentation has a few rules to enforce that, making the maintenance a no-brainer. - Some wait events were added to the code, but not documented, so this cannot be missed now. - The order of the tables for each wait event class is enforced in the documentation (the input .txt file does so as well for clarity, though this is not mandatory). - Less code, shaving 1.2k lines from the tree, with 1/3 of the savings coming from the code, the rest from the documentation. The wait event types "Lock" and "LWLock" still have their own code path for their code, hence only the documentation is created for them. These classes are listed with a special marker called WAIT_EVENT_DOCONLY in the input file. Adding a new wait event now requires only an update of wait_event_names.txt, with "Lock" and "LWLock" treated as exceptions. This commit has been tested with configure/Makefile, the CI and VPATH build. clean, distclean and maintainer-clean were working fine. Author: Bertrand Drouvot, Michael Paquier Discussion: https://postgr.es/m/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9b98@gmail.com
2023-07-05 03:53:11 +02:00
<note>
<para>
Support custom wait events for wait event type "Extension" Two backend routines are added to allow extension to allocate and define custom wait events, all of these being allocated in the type "Extension": * WaitEventExtensionNew(), that allocates a wait event ID computed from a counter in shared memory. * WaitEventExtensionRegisterName(), to associate a custom string to the wait event ID allocated. Note that this includes an example of how to use this new facility in worker_spi with tests in TAP for various scenarios, and some documentation about how to use them. Any code in the tree that currently uses WAIT_EVENT_EXTENSION could switch to this new facility to define custom wait events. This is left as work for future patches. Author: Masahiro Ikeda Reviewed-by: Andres Freund, Michael Paquier, Tristan Partin, Bharath Rupireddy Discussion: https://postgr.es/m/b9f5411acda0cf15c8fbb767702ff43e@oss.nttdata.com
2023-07-31 10:09:24 +02:00
Extensions can add <literal>Extension</literal> and
Doc: suppress "exceed the available area" warning in PDF build. Allow a line break in example output, as we have done elsewhere. Overlength output was added in commit 1e68e43d3. While here, adjust some shaky grammar in an adjacent note (from a different commit, c9af05465). Per buildfarm.
2023-10-03 20:13:53 +02:00
<literal>LWLock</literal> events
to the lists shown in <xref linkend="wait-event-extension-table"/> and
Support custom wait events for wait event type "Extension" Two backend routines are added to allow extension to allocate and define custom wait events, all of these being allocated in the type "Extension": * WaitEventExtensionNew(), that allocates a wait event ID computed from a counter in shared memory. * WaitEventExtensionRegisterName(), to associate a custom string to the wait event ID allocated. Note that this includes an example of how to use this new facility in worker_spi with tests in TAP for various scenarios, and some documentation about how to use them. Any code in the tree that currently uses WAIT_EVENT_EXTENSION could switch to this new facility to define custom wait events. This is left as work for future patches. Author: Masahiro Ikeda Reviewed-by: Andres Freund, Michael Paquier, Tristan Partin, Bharath Rupireddy Discussion: https://postgr.es/m/b9f5411acda0cf15c8fbb767702ff43e@oss.nttdata.com
2023-07-31 10:09:24 +02:00
<xref linkend="wait-event-lwlock-table"/>. In some cases, the name
Doc: suppress "exceed the available area" warning in PDF build. Allow a line break in example output, as we have done elsewhere. Overlength output was added in commit 1e68e43d3. While here, adjust some shaky grammar in an adjacent note (from a different commit, c9af05465). Per buildfarm.
2023-10-03 20:13:53 +02:00
of an <literal>LWLock</literal> assigned by an extension will not be
available in all server processes. It might be reported as just
Support custom wait events for wait event type "Extension" Two backend routines are added to allow extension to allocate and define custom wait events, all of these being allocated in the type "Extension": * WaitEventExtensionNew(), that allocates a wait event ID computed from a counter in shared memory. * WaitEventExtensionRegisterName(), to associate a custom string to the wait event ID allocated. Note that this includes an example of how to use this new facility in worker_spi with tests in TAP for various scenarios, and some documentation about how to use them. Any code in the tree that currently uses WAIT_EVENT_EXTENSION could switch to this new facility to define custom wait events. This is left as work for future patches. Author: Masahiro Ikeda Reviewed-by: Andres Freund, Michael Paquier, Tristan Partin, Bharath Rupireddy Discussion: https://postgr.es/m/b9f5411acda0cf15c8fbb767702ff43e@oss.nttdata.com
2023-07-31 10:09:24 +02:00
<quote><literal>extension</literal></quote> rather than the
Generate automatically code and documentation related to wait events The documentation and the code is generated automatically from a new file called wait_event_names.txt, formatted in sections dedicated to each wait event class (Timeout, Lock, IO, etc.) with three tab-separated fields: - C symbol in enums - Format in the system views - Description in the docs Using this approach has several advantages, as we have proved to be rather bad in maintaining this area of the tree across the years: - The order of each item in the documentation and the code, which should be alphabetical, has become incorrect multiple times, and the script generating the code and documentation has a few rules to enforce that, making the maintenance a no-brainer. - Some wait events were added to the code, but not documented, so this cannot be missed now. - The order of the tables for each wait event class is enforced in the documentation (the input .txt file does so as well for clarity, though this is not mandatory). - Less code, shaving 1.2k lines from the tree, with 1/3 of the savings coming from the code, the rest from the documentation. The wait event types "Lock" and "LWLock" still have their own code path for their code, hence only the documentation is created for them. These classes are listed with a special marker called WAIT_EVENT_DOCONLY in the input file. Adding a new wait event now requires only an update of wait_event_names.txt, with "Lock" and "LWLock" treated as exceptions. This commit has been tested with configure/Makefile, the CI and VPATH build. clean, distclean and maintainer-clean were working fine. Author: Bertrand Drouvot, Michael Paquier Discussion: https://postgr.es/m/77a86b3a-c4a8-5f5d-69b9-d70bbf2e9b98@gmail.com
2023-07-05 03:53:11 +02:00
extension-assigned name.
</para>
</note>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-replication-view">
<title><structname>pg_stat_replication</structname></title>
<indexterm>
<primary>pg_stat_replication</primary>
</indexterm>
<para>
The <structname>pg_stat_replication</structname> view will contain one row
per WAL sender process, showing statistics about replication to that
sender's connected standby server. Only directly connected standbys are
listed; no information is available about downstream standby servers.
</para>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<table id="pg-stat-replication-view" xreflabel="pg_stat_replication">
<title><structname>pg_stat_replication</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of a WAL sender process
</para></entry>
</row>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usesysid</structfield> <type>oid</type>
</para>
<para>
OID of the user logged into this WAL sender process
</para></entry>
</row>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>usename</structfield> <type>name</type>
</para>
<para>
Name of the user logged into this WAL sender process
</para></entry>
</row>
Replication lag tracking for walsenders Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication. Implements a lag tracker module that reports the lag times based upon measurements of the time taken for recent WAL to be written, flushed and replayed and for the sender to hear about it. These times represent the commit lag that was (or would have been) introduced by each synchronous commit level, if the remote server was configured as a synchronous standby. For an asynchronous standby, the replay_lag column approximates the delay before recent transactions became visible to queries. If the standby server has entirely caught up with the sending server and there is no more WAL activity, the most recently measured lag times will continue to be displayed for a short time and then show NULL. Physical replication lag tracking is automatic. Logical replication tracking is possible but is the responsibility of the logical decoding plugin. Tracking is a private module operating within each walsender individually, with values reported to shared memory. Module not used outside of walsender. Design and code is good enough now to commit - kudos to the author. In many ways a difficult topic, with important and subtle behaviour so this shoudl be expected to generate discussion and multiple open items: Test now! Author: Thomas Munro, following designs by Fujii Masao and Simon Riggs Review: Simon Riggs, Ian Barwick and Craig Ringer
2017-03-23 15:05:28 +01:00
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>application_name</structfield> <type>text</type>
</para>
<para>
Name of the application that is connected
to this WAL sender
</para></entry>
</row>
Replication lag tracking for walsenders Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication. Implements a lag tracker module that reports the lag times based upon measurements of the time taken for recent WAL to be written, flushed and replayed and for the sender to hear about it. These times represent the commit lag that was (or would have been) introduced by each synchronous commit level, if the remote server was configured as a synchronous standby. For an asynchronous standby, the replay_lag column approximates the delay before recent transactions became visible to queries. If the standby server has entirely caught up with the sending server and there is no more WAL activity, the most recently measured lag times will continue to be displayed for a short time and then show NULL. Physical replication lag tracking is automatic. Logical replication tracking is possible but is the responsibility of the logical decoding plugin. Tracking is a private module operating within each walsender individually, with values reported to shared memory. Module not used outside of walsender. Design and code is good enough now to commit - kudos to the author. In many ways a difficult topic, with important and subtle behaviour so this shoudl be expected to generate discussion and multiple open items: Test now! Author: Thomas Munro, following designs by Fujii Masao and Simon Riggs Review: Simon Riggs, Ian Barwick and Craig Ringer
2017-03-23 15:05:28 +01:00
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_addr</structfield> <type>inet</type>
</para>
<para>
IP address of the client connected to this WAL sender.
If this field is null, it indicates that the client is
connected via a Unix socket on the server machine.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_hostname</structfield> <type>text</type>
</para>
<para>
Host name of the connected client, as reported by a
reverse DNS lookup of <structfield>client_addr</structfield>. This field will
only be non-null for IP connections, and only when <xref linkend="guc-log-hostname"/> is enabled.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_port</structfield> <type>integer</type>
</para>
<para>
TCP port number that the client is using for communication
with this WAL sender, or <literal>-1</literal> if a Unix socket is used
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backend_start</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time when this process was started, i.e., when the
client connected to this WAL sender
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backend_xmin</structfield> <type>xid</type>
</para>
<para>
This standby's <literal>xmin</literal> horizon reported
by <xref linkend="guc-hot-standby-feedback"/>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>state</structfield> <type>text</type>
</para>
<para>
Current WAL sender state.
Possible values are:
<itemizedlist>
<listitem>
<para>
<literal>startup</literal>: This WAL sender is starting up.
</para>
</listitem>
<listitem>
<para>
<literal>catchup</literal>: This WAL sender's connected standby is
catching up with the primary.
</para>
</listitem>
<listitem>
<para>
<literal>streaming</literal>: This WAL sender is streaming changes
after its connected standby server has caught up with the primary.
</para>
</listitem>
<listitem>
<para>
<literal>backup</literal>: This WAL sender is sending a backup.
</para>
</listitem>
<listitem>
<para>
<literal>stopping</literal>: This WAL sender is stopping.
</para>
</listitem>
</itemizedlist>
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sent_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Last write-ahead log location sent on this connection
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>write_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Last write-ahead log location written to disk by this standby
server
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>flush_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Last write-ahead log location flushed to disk by this standby
server
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>replay_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Last write-ahead log location replayed into the database on this
standby server
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>write_lag</structfield> <type>interval</type>
</para>
<para>
Time elapsed between flushing recent WAL locally and receiving
notification that this standby server has written it (but not yet
flushed it or applied it). This can be used to gauge the delay that
<literal>synchronous_commit</literal> level
<literal>remote_write</literal> incurred while committing if this
server was configured as a synchronous standby.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>flush_lag</structfield> <type>interval</type>
</para>
<para>
Time elapsed between flushing recent WAL locally and receiving
notification that this standby server has written and flushed it
(but not yet applied it). This can be used to gauge the delay that
<literal>synchronous_commit</literal> level
<literal>on</literal> incurred while committing if this
server was configured as a synchronous standby.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>replay_lag</structfield> <type>interval</type>
</para>
<para>
Time elapsed between flushing recent WAL locally and receiving
notification that this standby server has written, flushed and
applied it. This can be used to gauge the delay that
<literal>synchronous_commit</literal> level
<literal>remote_apply</literal> incurred while committing if this
server was configured as a synchronous standby.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sync_priority</structfield> <type>integer</type>
</para>
<para>
Priority of this standby server for being chosen as the
synchronous standby in a priority-based synchronous replication.
This has no effect in a quorum-based synchronous replication.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sync_state</structfield> <type>text</type>
</para>
<para>
Synchronous state of this standby server.
Possible values are:
<itemizedlist>
<listitem>
<para>
<literal>async</literal>: This standby server is asynchronous.
</para>
</listitem>
<listitem>
<para>
<literal>potential</literal>: This standby server is now asynchronous,
but can potentially become synchronous if one of current
synchronous ones fails.
</para>
</listitem>
<listitem>
<para>
<literal>sync</literal>: This standby server is synchronous.
</para>
</listitem>
<listitem>
<para>
<literal>quorum</literal>: This standby server is considered as a candidate
for quorum standbys.
</para>
</listitem>
</itemizedlist>
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>reply_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Send time of last reply message received from standby server
</para></entry>
</row>
</tbody>
</tgroup>
</table>
<para>
The lag times reported in the <structname>pg_stat_replication</structname>
view are measurements of the time taken for recent WAL to be written,
flushed and replayed and for the sender to know about it. These times
represent the commit delay that was (or would have been) introduced by each
synchronous commit level, if the remote server was configured as a
synchronous standby. For an asynchronous standby, the
<structfield>replay_lag</structfield> column approximates the delay
before recent transactions became visible to queries. If the standby
server has entirely caught up with the sending server and there is no more
WAL activity, the most recently measured lag times will continue to be
displayed for a short time and then show NULL.
</para>
<para>
Lag times work automatically for physical replication. Logical decoding
plugins may optionally emit tracking messages; if they do not, the tracking
mechanism will simply display NULL lag.
</para>
<note>
<para>
The reported lag times are not predictions of how long it will take for
the standby to catch up with the sending server assuming the current
rate of replay. Such a system would show similar times while new WAL is
being generated, but would differ when the sender becomes idle. In
particular, when the standby has caught up completely,
<structname>pg_stat_replication</structname> shows the time taken to
write, flush and replay the most recent reported WAL location rather than
zero as some users might expect. This is consistent with the goal of
measuring synchronous commit and transaction visibility delays for
recent write transactions.
To reduce confusion for users expecting a different model of lag, the
lag columns revert to NULL after a short time on a fully replayed idle
system. Monitoring systems should choose whether to represent this
Replication lag tracking for walsenders Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication. Implements a lag tracker module that reports the lag times based upon measurements of the time taken for recent WAL to be written, flushed and replayed and for the sender to hear about it. These times represent the commit lag that was (or would have been) introduced by each synchronous commit level, if the remote server was configured as a synchronous standby. For an asynchronous standby, the replay_lag column approximates the delay before recent transactions became visible to queries. If the standby server has entirely caught up with the sending server and there is no more WAL activity, the most recently measured lag times will continue to be displayed for a short time and then show NULL. Physical replication lag tracking is automatic. Logical replication tracking is possible but is the responsibility of the logical decoding plugin. Tracking is a private module operating within each walsender individually, with values reported to shared memory. Module not used outside of walsender. Design and code is good enough now to commit - kudos to the author. In many ways a difficult topic, with important and subtle behaviour so this shoudl be expected to generate discussion and multiple open items: Test now! Author: Thomas Munro, following designs by Fujii Masao and Simon Riggs Review: Simon Riggs, Ian Barwick and Craig Ringer
2017-03-23 15:05:28 +01:00
as missing data, zero or continue to display the last known value.
</para>
</note>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
<sect2 id="monitoring-pg-stat-replication-slots-view">
<title><structname>pg_stat_replication_slots</structname></title>
<indexterm>
<primary>pg_stat_replication_slots</primary>
</indexterm>
<para>
The <structname>pg_stat_replication_slots</structname> view will contain
one row per logical replication slot, showing statistics about its usage.
</para>
<table id="pg-stat-replication-slots-view" xreflabel="pg_stat_replication_slots">
<title><structname>pg_stat_replication_slots</structname> View</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Change the attribute name in pg_stat_replication_slots view. Change the attribute 'name' to 'slot_name' in pg_stat_replication_slots view to make it clear and that way we will be consistent with the other places like pg_stat_wal_receiver view where we display the same attribute. In the passing, fix the typo in one of the macros in the related code. Bump the catversion as we have modified the name in the catalog as well. Reported-by: Noriyoshi Shinoda Author: Noriyoshi Shinoda Reviewed-by: Sawada Masahiko and Amit Kapila Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-20 06:54:36 +02:00
<structfield>slot_name</structfield> <type>text</type>
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
</para>
<para>
A unique, cluster-wide identifier for the replication slot
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>spill_txns</structfield> <type>bigint</type>
</para>
<para>
doc: Improve wording of section for repslot statistics This documentation has been added in 9868167, so no backpatch is needed. Author: Justin Pryzby, Michael Paquier Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2021-01-29 06:24:49 +01:00
Number of transactions spilled to disk once the memory used by
logical decoding to decode changes from WAL has exceeded
Update description of spilled counters in pg_stat_replication_slots view. This is to make the description of spilled counters clear. Author: Amit Kapila Reviewed-by: Sawada Masahiko Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-27 03:52:39 +01:00
<literal>logical_decoding_work_mem</literal>. The counter gets
doc: Spell checking
2021-07-16 10:35:38 +02:00
incremented for both top-level transactions and subtransactions.
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>spill_count</structfield> <type>bigint</type>
</para>
<para>
doc: Improve wording of section for repslot statistics This documentation has been added in 9868167, so no backpatch is needed. Author: Justin Pryzby, Michael Paquier Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2021-01-29 06:24:49 +01:00
Number of times transactions were spilled to disk while decoding
changes from WAL for this slot. This counter is incremented each time
a transaction is spilled, and the same transaction may be spilled
multiple times.
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>spill_bytes</structfield> <type>bigint</type>
</para>
<para>
Update description of spilled counters in pg_stat_replication_slots view. This is to make the description of spilled counters clear. Author: Amit Kapila Reviewed-by: Sawada Masahiko Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-27 03:52:39 +01:00
Amount of decoded transaction data spilled to disk while performing
decoding of changes from WAL for this slot. This and other spill
Minor improvements in description of spilled counters in pg_stat_replication_slots view. Per a suggestion by Justin Pryzby. Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-28 02:58:51 +01:00
counters can be used to gauge the I/O which occurred during logical
decoding and allow tuning <literal>logical_decoding_work_mem</literal>.
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
</para></entry>
</row>
Track statistics for streaming of changes from ReorderBuffer. This adds the statistics about transactions streamed to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. Commit 9868167500 has added the basic infrastructure to capture the stats of slot and this commit extends the statistics collector to track additional information about slots. Bump the catversion as we have added new columns in the catalog entry. Author: Ajin Cherian and Amit Kapila Reviewed-by: Sawada Masahiko and Dilip Kumar Discussion: https://postgr.es/m/CAA4eK1+chpEomLzgSoky-D31qev19AmECNiEAietPQUGEFhtVA@mail.gmail.com
2020-10-29 04:41:51 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stream_txns</structfield> <type>bigint</type>
</para>
<para>
doc: Improve wording of section for repslot statistics This documentation has been added in 9868167, so no backpatch is needed. Author: Justin Pryzby, Michael Paquier Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2021-01-29 06:24:49 +01:00
Number of in-progress transactions streamed to the decoding output
plugin after the memory used by logical decoding to decode changes
from WAL for this slot has exceeded
<literal>logical_decoding_work_mem</literal>. Streaming only
doc: Spell checking
2021-07-16 10:35:38 +02:00
works with top-level transactions (subtransactions can't be streamed
doc: Improve wording of section for repslot statistics This documentation has been added in 9868167, so no backpatch is needed. Author: Justin Pryzby, Michael Paquier Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2021-01-29 06:24:49 +01:00
independently), so the counter is not incremented for subtransactions.
Track statistics for streaming of changes from ReorderBuffer. This adds the statistics about transactions streamed to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. Commit 9868167500 has added the basic infrastructure to capture the stats of slot and this commit extends the statistics collector to track additional information about slots. Bump the catversion as we have added new columns in the catalog entry. Author: Ajin Cherian and Amit Kapila Reviewed-by: Sawada Masahiko and Dilip Kumar Discussion: https://postgr.es/m/CAA4eK1+chpEomLzgSoky-D31qev19AmECNiEAietPQUGEFhtVA@mail.gmail.com
2020-10-29 04:41:51 +01:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stream_count</structfield><type>bigint</type>
</para>
<para>
Number of times in-progress transactions were streamed to the decoding
doc: Improve wording of section for repslot statistics This documentation has been added in 9868167, so no backpatch is needed. Author: Justin Pryzby, Michael Paquier Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2021-01-29 06:24:49 +01:00
output plugin while decoding changes from WAL for this slot. This
counter is incremented each time a transaction is streamed, and the
same transaction may be streamed multiple times.
Track statistics for streaming of changes from ReorderBuffer. This adds the statistics about transactions streamed to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. Commit 9868167500 has added the basic infrastructure to capture the stats of slot and this commit extends the statistics collector to track additional information about slots. Bump the catversion as we have added new columns in the catalog entry. Author: Ajin Cherian and Amit Kapila Reviewed-by: Sawada Masahiko and Dilip Kumar Discussion: https://postgr.es/m/CAA4eK1+chpEomLzgSoky-D31qev19AmECNiEAietPQUGEFhtVA@mail.gmail.com
2020-10-29 04:41:51 +01:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stream_bytes</structfield><type>bigint</type>
</para>
<para>
Update replication statistics after every stream/spill. Currently, replication slot statistics are updated at prepare, commit, and rollback. Now, if the transaction is interrupted the stats might not get updated. Fixed this by updating replication statistics after every stream/spill. In passing update the docs to change the description of some of the slot stats. Author: Vignesh C, Sawada Masahiko Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
2021-05-06 07:51:26 +02:00
Amount of transaction data decoded for streaming in-progress
transactions to the decoding output plugin while decoding changes from
WAL for this slot. This and other streaming counters for this slot can
be used to tune <literal>logical_decoding_work_mem</literal>.
Track statistics for streaming of changes from ReorderBuffer. This adds the statistics about transactions streamed to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. Commit 9868167500 has added the basic infrastructure to capture the stats of slot and this commit extends the statistics collector to track additional information about slots. Bump the catversion as we have added new columns in the catalog entry. Author: Ajin Cherian and Amit Kapila Reviewed-by: Sawada Masahiko and Dilip Kumar Discussion: https://postgr.es/m/CAA4eK1+chpEomLzgSoky-D31qev19AmECNiEAietPQUGEFhtVA@mail.gmail.com
2020-10-29 04:41:51 +01:00
</para>
</entry>
</row>
Add information of total data processed to replication slot stats. This adds the statistics about total transactions count and total transaction data logically sent to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats. Suggested-by: Andres Freund Author: Vignesh C and Amit Kapila Reviewed-by: Sawada Masahiko, Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
2021-04-16 04:04:43 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>total_txns</structfield> <type>bigint</type>
</para>
<para>
Number of decoded transactions sent to the decoding output plugin for
doc: Spell checking
2021-07-16 10:35:38 +02:00
this slot. This counts top-level transactions only, and is not incremented
Fix test case added by commit f5fc2f5b23. In the new test after resetting the stats, we were not waiting for the stats message to be delivered. Also, we need to decode the results for the new test, otherwise, it will show the old stats. In passing, a. Change docs added by commit f5fc2f5b23 as per suggestion by Justin Pryzby. b. Bump the PGSTAT_FILE_FORMAT_ID as commit f5fc2f5b23 changes the file format of stats. Reported-by: Tom Lane based on buildfarm reports Author: Vignesh C, Justin Pryzby Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
2021-04-19 05:32:47 +02:00
for subtransactions. Note that this includes the transactions that are
streamed and/or spilled.
Add information of total data processed to replication slot stats. This adds the statistics about total transactions count and total transaction data logically sent to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats. Suggested-by: Andres Freund Author: Vignesh C and Amit Kapila Reviewed-by: Sawada Masahiko, Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
2021-04-16 04:04:43 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>total_bytes</structfield><type>bigint</type>
</para>
<para>
Update replication statistics after every stream/spill. Currently, replication slot statistics are updated at prepare, commit, and rollback. Now, if the transaction is interrupted the stats might not get updated. Fixed this by updating replication statistics after every stream/spill. In passing update the docs to change the description of some of the slot stats. Author: Vignesh C, Sawada Masahiko Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
2021-05-06 07:51:26 +02:00
Amount of transaction data decoded for sending transactions to the
decoding output plugin while decoding changes from WAL for this slot.
Note that this includes data that is streamed and/or spilled.
Add information of total data processed to replication slot stats. This adds the statistics about total transactions count and total transaction data logically sent to the decoding output plugin from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats. Suggested-by: Andres Freund Author: Vignesh C and Amit Kapila Reviewed-by: Sawada Masahiko, Amit Kapila Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
2021-04-16 04:04:43 +02:00
</para>
</entry>
</row>
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset
</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect2>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<sect2 id="monitoring-pg-stat-wal-receiver-view">
<title><structname>pg_stat_wal_receiver</structname></title>
<indexterm>
<primary>pg_stat_wal_receiver</primary>
</indexterm>
<para>
The <structname>pg_stat_wal_receiver</structname> view will contain only
one row, showing statistics about the WAL receiver from that receiver's
connected server.
</para>
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
<table id="pg-stat-wal-receiver-view" xreflabel="pg_stat_wal_receiver">
<title><structname>pg_stat_wal_receiver</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of the WAL receiver process
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>status</structfield> <type>text</type>
</para>
<para>
Activity status of the WAL receiver process
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>receive_start_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
First write-ahead log location used when WAL receiver is
started
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>receive_start_tli</structfield> <type>integer</type>
</para>
<para>
First timeline number used when WAL receiver is started
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Make pg_stat_wal_receiver consistent with the WAL receiver's shmem info d140f2f3 has renamed receivedUpto to flushedUpto, and has added writtenUpto to the WAL receiver's shared memory information, but pg_stat_wal_receiver was not consistent with that. This commit renames received_lsn to flushed_lsn, and adds a new column called written_lsn. Bump catalog version. Author: Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/20200515090817.GA212736@paquier.xyz
2020-05-17 02:22:07 +02:00
<structfield>written_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Last write-ahead log location already received and written to disk,
but not flushed. This should not be used for data integrity checks.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>flushed_lsn</structfield> <type>pg_lsn</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Last write-ahead log location already received and flushed to
disk, the initial value of this field being the first log location used
when WAL receiver is started
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>received_tli</structfield> <type>integer</type>
</para>
<para>
Timeline number of last write-ahead log location received and
flushed to disk, the initial value of this field being the timeline
number of the first log location used when WAL receiver is started
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_msg_send_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Send time of last message received from origin WAL sender
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_msg_receipt_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Receipt time of last message received from origin WAL sender
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>latest_end_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Last write-ahead log location reported to origin WAL sender
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>latest_end_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time of last write-ahead log location reported to origin WAL sender
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>slot_name</structfield> <type>text</type>
</para>
<para>
Replication slot name used by this WAL receiver
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sender_host</structfield> <type>text</type>
</para>
<para>
Host of the <productname>PostgreSQL</productname> instance
this WAL receiver is connected to. This can be a host name,
an IP address, or a directory path if the connection is via
Unix socket. (The path case can be distinguished because it
will always be an absolute path, beginning with <literal>/</literal>.)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sender_port</structfield> <type>integer</type>
</para>
<para>
Port number of the <productname>PostgreSQL</productname> instance
this WAL receiver is connected to.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conninfo</structfield> <type>text</type>
</para>
<para>
Connection string used by this WAL receiver,
with security-sensitive fields obfuscated.
</para></entry>
</row>
</tbody>
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
<sect2 id="monitoring-pg-stat-recovery-prefetch">
<title><structname>pg_stat_recovery_prefetch</structname></title>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<indexterm>
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
<primary>pg_stat_recovery_prefetch</primary>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</indexterm>
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
<para>
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
The <structname>pg_stat_recovery_prefetch</structname> view will contain
only one row. The columns <structfield>wal_distance</structfield>,
<structfield>block_distance</structfield> and
<structfield>io_depth</structfield> show current values, and the
other columns show cumulative counters that can be reset
with the <function>pg_stat_reset_shared</function> function.
pgstat: add WAL receiver status view & SRF This new view provides insight into the state of a running WAL receiver in a HOT standby node. The information returned includes the PID of the WAL receiver process, its status (stopped, starting, streaming, etc), start LSN and TLI, last received LSN and TLI, timestamp of last message send and receipt, latest end-of-WAL LSN and time, and the name of the slot (if any). Access to the detailed data is only granted to superusers; others only get the PID. Author: Michael Paquier Reviewer: Haribabu Kommi
2016-01-07 20:21:19 +01:00
</para>
Prefetch data referenced by the WAL, take II. Introduce a new GUC recovery_prefetch. When enabled, look ahead in the WAL and try to initiate asynchronous reading of referenced data blocks that are not yet cached in our buffer pool. For now, this is done with posix_fadvise(), which has several caveats. Since not all OSes have that system call, "try" is provided so that it can be enabled where available. Better mechanisms for asynchronous I/O are possible in later work. Set to "try" for now for test coverage. Default setting to be finalized before release. The GUC wal_decode_buffer_size limits the distance we can look ahead in bytes of decoded data. The existing GUC maintenance_io_concurrency is used to limit the number of concurrent I/Os allowed, based on pessimistic heuristics used to infer that I/Os have begun and completed. We'll also not look more than maintenance_io_concurrency * 4 block references ahead. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (earlier version) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (earlier version) Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (earlier version) Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com> (earlier version) Tested-by: Dmitry Dolgov <9erthalion6@gmail.com> (earlier version) Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com
2022-04-07 09:28:40 +02:00
<table id="pg-stat-recovery-prefetch-view" xreflabel="pg_stat_recovery_prefetch">
<title><structname>pg_stat_recovery_prefetch</structname> View</title>
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
<tgroup cols="1">
Prefetch data referenced by the WAL, take II. Introduce a new GUC recovery_prefetch. When enabled, look ahead in the WAL and try to initiate asynchronous reading of referenced data blocks that are not yet cached in our buffer pool. For now, this is done with posix_fadvise(), which has several caveats. Since not all OSes have that system call, "try" is provided so that it can be enabled where available. Better mechanisms for asynchronous I/O are possible in later work. Set to "try" for now for test coverage. Default setting to be finalized before release. The GUC wal_decode_buffer_size limits the distance we can look ahead in bytes of decoded data. The existing GUC maintenance_io_concurrency is used to limit the number of concurrent I/Os allowed, based on pessimistic heuristics used to infer that I/Os have begun and completed. We'll also not look more than maintenance_io_concurrency * 4 block references ahead. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (earlier version) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (earlier version) Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (earlier version) Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com> (earlier version) Tested-by: Dmitry Dolgov <9erthalion6@gmail.com> (earlier version) Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com
2022-04-07 09:28:40 +02:00
<thead>
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Prefetch data referenced by the WAL, take II. Introduce a new GUC recovery_prefetch. When enabled, look ahead in the WAL and try to initiate asynchronous reading of referenced data blocks that are not yet cached in our buffer pool. For now, this is done with posix_fadvise(), which has several caveats. Since not all OSes have that system call, "try" is provided so that it can be enabled where available. Better mechanisms for asynchronous I/O are possible in later work. Set to "try" for now for test coverage. Default setting to be finalized before release. The GUC wal_decode_buffer_size limits the distance we can look ahead in bytes of decoded data. The existing GUC maintenance_io_concurrency is used to limit the number of concurrent I/Os allowed, based on pessimistic heuristics used to infer that I/Os have begun and completed. We'll also not look more than maintenance_io_concurrency * 4 block references ahead. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (earlier version) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (earlier version) Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (earlier version) Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com> (earlier version) Tested-by: Dmitry Dolgov <9erthalion6@gmail.com> (earlier version) Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com
2022-04-07 09:28:40 +02:00
</row>
</thead>
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
<tbody>
<row>
<entry role="catalog_table_entry">
Doc: Document pg_stat_recovery_prefetch.stats_reset. This column was missing from the table that describes the new view. Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com> Discussion: https://postgr.es/m/DM4PR84MB173401C19A0EB9B1CAAB197CEED29@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
2022-05-29 06:33:26 +02:00
<para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
<para role="column_definition">
<structfield>prefetch</structfield> <type>bigint</type>
</para>
<para>
Number of blocks prefetched because they were not in the buffer pool
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>hit</structfield> <type>bigint</type>
</para>
<para>
Number of blocks not prefetched because they were already in the buffer pool
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>skip_init</structfield> <type>bigint</type>
</para>
<para>
Number of blocks not prefetched because they would be zero-initialized
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>skip_new</structfield> <type>bigint</type>
</para>
<para>
Number of blocks not prefetched because they didn't exist yet
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>skip_fpw</structfield> <type>bigint</type>
</para>
<para>
Number of blocks not prefetched because a full page image was included in the WAL
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>skip_rep</structfield> <type>bigint</type>
</para>
<para>
Number of blocks not prefetched because they were already recently prefetched
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>wal_distance</structfield> <type>int</type>
</para>
<para>
How many bytes ahead the prefetcher is looking
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>block_distance</structfield> <type>int</type>
</para>
<para>
How many blocks ahead the prefetcher is looking
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>io_depth</structfield> <type>int</type>
</para>
<para>
How many prefetches have been initiated but are not yet known to have completed
</para>
</entry>
</row>
Prefetch data referenced by the WAL, take II. Introduce a new GUC recovery_prefetch. When enabled, look ahead in the WAL and try to initiate asynchronous reading of referenced data blocks that are not yet cached in our buffer pool. For now, this is done with posix_fadvise(), which has several caveats. Since not all OSes have that system call, "try" is provided so that it can be enabled where available. Better mechanisms for asynchronous I/O are possible in later work. Set to "try" for now for test coverage. Default setting to be finalized before release. The GUC wal_decode_buffer_size limits the distance we can look ahead in bytes of decoded data. The existing GUC maintenance_io_concurrency is used to limit the number of concurrent I/Os allowed, based on pessimistic heuristics used to infer that I/Os have begun and completed. We'll also not look more than maintenance_io_concurrency * 4 block references ahead. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (earlier version) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (earlier version) Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (earlier version) Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com> (earlier version) Tested-by: Dmitry Dolgov <9erthalion6@gmail.com> (earlier version) Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com
2022-04-07 09:28:40 +02:00
</tbody>
</tgroup>
</table>
Fix documentation for pg_stat_recovery_prefetch. The table was in the wrong section and using an older type of link, as reported by Sirisha, and also using an older table layout, as I noticed while trying to figure out how and when it might have got out of sync. Defect in commit 5dc0418f. Author: sirisha chamarthi <sirichamarthi22@gmail.com> Author: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAKrAKeVk-LRHMdyT6x_p33eF6dCorM2jed5h_eHdRdv0reSYTA@mail.gmail.com
2022-04-12 11:19:47 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-subscription">
<title><structname>pg_stat_subscription</structname></title>
<indexterm>
<primary>pg_stat_subscription</primary>
</indexterm>
Prefetch data referenced by the WAL, take II. Introduce a new GUC recovery_prefetch. When enabled, look ahead in the WAL and try to initiate asynchronous reading of referenced data blocks that are not yet cached in our buffer pool. For now, this is done with posix_fadvise(), which has several caveats. Since not all OSes have that system call, "try" is provided so that it can be enabled where available. Better mechanisms for asynchronous I/O are possible in later work. Set to "try" for now for test coverage. Default setting to be finalized before release. The GUC wal_decode_buffer_size limits the distance we can look ahead in bytes of decoded data. The existing GUC maintenance_io_concurrency is used to limit the number of concurrent I/Os allowed, based on pessimistic heuristics used to infer that I/Os have begun and completed. We'll also not look more than maintenance_io_concurrency * 4 block references ahead. Reviewed-by: Julien Rouhaud <rjuju123@gmail.com> Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> (earlier version) Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> (earlier version) Tested-by: Tomas Vondra <tomas.vondra@2ndquadrant.com> (earlier version) Tested-by: Jakub Wartak <Jakub.Wartak@tomtom.com> (earlier version) Tested-by: Dmitry Dolgov <9erthalion6@gmail.com> (earlier version) Tested-by: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> (earlier version) Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com
2022-04-07 09:28:40 +02:00
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<table id="pg-stat-subscription" xreflabel="pg_stat_subscription">
<title><structname>pg_stat_subscription</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subid</structfield> <type>oid</type>
</para>
<para>
OID of the subscription
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subname</structfield> <type>name</type>
</para>
<para>
Name of the subscription
</para></entry>
</row>
Add worker type to pg_stat_subscription. Thanks to commit 2a8b40e368, the logical replication worker type is easily determined. The worker type could already be deduced via other columns such as leader_pid and relid, but that is unnecessary complexity for users. Bumps catversion. Author: Peter Smith Reviewed-by: Michael Paquier, Maxim Orlov, Amit Kapila Discussion: https://postgr.es/m/CAHut%2BPtmbSMfErSk0S7xxVdZJ9XVE3xVLhqBTmT91kf57BeKDQ%40mail.gmail.com
2023-09-25 23:12:43 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>worker_type</structfield> <type>text</type>
</para>
<para>
Type of the subscription worker process. Possible types are
<literal>apply</literal>, <literal>parallel apply</literal>, and
<literal>table synchronization</literal>.
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of the subscription worker process
</para></entry>
</row>
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>leader_pid</structfield> <type>integer</type>
</para>
<para>
Process ID of the leader apply worker if this process is a parallel
Add worker type to pg_stat_subscription. Thanks to commit 2a8b40e368, the logical replication worker type is easily determined. The worker type could already be deduced via other columns such as leader_pid and relid, but that is unnecessary complexity for users. Bumps catversion. Author: Peter Smith Reviewed-by: Michael Paquier, Maxim Orlov, Amit Kapila Discussion: https://postgr.es/m/CAHut%2BPtmbSMfErSk0S7xxVdZJ9XVE3xVLhqBTmT91kf57BeKDQ%40mail.gmail.com
2023-09-25 23:12:43 +02:00
apply worker; NULL if this process is a leader apply worker or a table
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
synchronization worker
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
OID of the relation that the worker is synchronizing; NULL for the
leader apply worker and parallel apply workers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>received_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Last write-ahead log location received, the initial value of
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
this field being 0; NULL for parallel apply workers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_msg_send_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
Send time of last message received from origin WAL sender; NULL for
parallel apply workers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_msg_receipt_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
Receipt time of last message received from origin WAL sender; NULL for
parallel apply workers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>latest_end_lsn</structfield> <type>pg_lsn</type>
</para>
<para>
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
Last write-ahead log location reported to origin WAL sender; NULL for
parallel apply workers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>latest_end_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time of last write-ahead log location reported to origin WAL
Display the leader apply worker's PID for parallel apply workers. Add leader_pid to pg_stat_subscription. leader_pid is the process ID of the leader apply worker if this process is a parallel apply worker. If this field is NULL, it indicates that the process is a leader apply worker or a synchronization worker. The new column makes it easier to distinguish parallel apply workers from other kinds of workers and helps to identify the leader for the parallel workers corresponding to a particular subscription. Additionally, update the leader_pid column in pg_stat_activity as well to display the PID of the leader apply worker for parallel apply workers. Author: Hou Zhijie Reviewed-by: Peter Smith, Sawada Masahiko, Amit Kapila, Shveta Mallik Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
2023-01-18 04:33:12 +01:00
sender; NULL for parallel apply workers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
</tbody>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<sect2 id="monitoring-pg-stat-subscription-stats">
<title><structname>pg_stat_subscription_stats</structname></title>
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
<indexterm>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<primary>pg_stat_subscription_stats</primary>
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</indexterm>
<para>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
The <structname>pg_stat_subscription_stats</structname> view will contain
one row per subscription.
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<table id="pg-stat-subscription-stats" xreflabel="pg_stat_subscription_stats">
<title><structname>pg_stat_subscription_stats</structname> View</title>
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subid</structfield> <type>oid</type>
</para>
<para>
OID of the subscription
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>subname</structfield> <type>name</type>
</para>
<para>
Name of the subscription
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<structfield>apply_error_count</structfield> <type>bigint</type>
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para>
<para>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
Number of times an error occurred while applying changes
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<structfield>sync_error_count</structfield> <type>bigint</type>
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para>
<para>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
Number of times an error occurred during the initial table
synchronization
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para>
<para>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
Time at which these statistics were last reset
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect2>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<sect2 id="monitoring-pg-stat-ssl-view">
<title><structname>pg_stat_ssl</structname></title>
<indexterm>
<primary>pg_stat_ssl</primary>
</indexterm>
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_ssl</structname> view will contain one row per
backend or WAL sender process, showing statistics about SSL usage on
this connection. It can be joined to <structname>pg_stat_activity</structname>
or <structname>pg_stat_replication</structname> on the
<structfield>pid</structfield> column to get more details about the
connection.
Logical replication - Add PUBLICATION catalogs and DDL - Add SUBSCRIPTION catalog and DDL - Define logical replication protocol and output plugin - Add logical replication workers From: Petr Jelinek <petr@2ndquadrant.com> Reviewed-by: Steve Singer <steve@ssinger.info> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Erik Rijkers <er@xs4all.nl> Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
2017-01-19 18:00:00 +01:00
</para>
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
<table id="pg-stat-ssl-view" xreflabel="pg_stat_ssl">
<title><structname>pg_stat_ssl</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of a backend or WAL sender process
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ssl</structfield> <type>boolean</type>
</para>
<para>
True if SSL is used on this connection
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>version</structfield> <type>text</type>
</para>
<para>
Version of SSL in use, or NULL if SSL is not in use
on this connection
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cipher</structfield> <type>text</type>
</para>
<para>
Name of SSL cipher in use, or NULL if SSL is not in use
on this connection
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>bits</structfield> <type>integer</type>
</para>
<para>
Number of bits in the encryption algorithm used, or NULL
if SSL is not used on this connection
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_dn</structfield> <type>text</type>
</para>
<para>
Distinguished Name (DN) field from the client certificate
used, or NULL if no client certificate was supplied or if SSL
is not in use on this connection. This field is truncated if the
DN field is longer than <symbol>NAMEDATALEN</symbol> (64 characters
in a standard build).
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>client_serial</structfield> <type>numeric</type>
</para>
<para>
Serial number of the client certificate, or NULL if no client
certificate was supplied or if SSL is not in use on this connection. The
combination of certificate serial number and certificate issuer uniquely
identifies a certificate (unless the issuer erroneously reuses serial
numbers).
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>issuer_dn</structfield> <type>text</type>
</para>
<para>
DN of the issuer of the client certificate, or NULL if no client
certificate was supplied or if SSL is not in use on this connection.
This field is truncated like <structfield>client_dn</structfield>.
</para></entry>
</row>
</tbody>
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-gssapi-view">
<title><structname>pg_stat_gssapi</structname></title>
<indexterm>
<primary>pg_stat_gssapi</primary>
</indexterm>
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_gssapi</structname> view will contain one row per
backend, showing information about GSSAPI usage on this connection. It can
be joined to <structname>pg_stat_activity</structname> or
<structname>pg_stat_replication</structname> on the
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
<structfield>pid</structfield> column to get more details about the
connection.
</para>
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
<table id="pg-stat-gssapi-view" xreflabel="pg_stat_gssapi">
<title><structname>pg_stat_gssapi</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of a backend
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>gss_authenticated</structfield> <type>boolean</type>
</para>
<para>
True if GSSAPI authentication was used for this connection
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>principal</structfield> <type>text</type>
</para>
<para>
Principal used to authenticate this connection, or NULL
if GSSAPI was not used to authenticate this connection. This
field is truncated if the principal is longer than
<symbol>NAMEDATALEN</symbol> (64 characters in a standard build).
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>encrypted</structfield> <type>boolean</type>
</para>
<para>
True if GSSAPI encryption is in use on this connection
</para></entry>
</row>
De-Revert "Add support for Kerberos credential delegation" This reverts commit 3d03b24c3 (Revert Add support for Kerberos credential delegation) which was committed on the grounds of concern about portability, but on further review and discussion, it's clear that we are better off explicitly requiring MIT Kerberos as that appears to be the only GSSAPI library currently that's under proper maintenance and ongoing development. The API used for storing credentials was added to MIT Kerberos over a decade ago while for the other libraries which appear to be mainly based on Heimdal, which exists explicitly to be a re-implementation of MIT Kerberos, the API never made it to a released version (even though it was added to the Heimdal git repo over 5 years ago..). This post-feature-freeze change was approved by the RMT. Discussion: https://postgr.es/m/ZDDO6jaESKaBgej0%40tamriel.snowman.net
2023-04-13 14:55:07 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>credentials_delegated</structfield> <type>boolean</type>
</para>
<para>
True if GSSAPI credentials were delegated on this connection.
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</tbody>
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-archiver-view">
<title><structname>pg_stat_archiver</structname></title>
<indexterm>
<primary>pg_stat_archiver</primary>
</indexterm>
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_archiver</structname> view will always have a
single row, containing data about the archiver process of the cluster.
GSSAPI encryption support On both the frontend and backend, prepare for GSSAPI encryption support by moving common code for error handling into a separate file. Fix a TODO for handling multiple status messages in the process. Eliminate the OIDs, which have not been needed for some time. Add frontend and backend encryption support functions. Keep the context initiation for authentication-only separate on both the frontend and backend in order to avoid concerns about changing the requested flags to include encryption support. In postmaster, pull GSSAPI authorization checking into a shared function. Also share the initiator name between the encryption and non-encryption codepaths. For HBA, add "hostgssenc" and "hostnogssenc" entries that behave similarly to their SSL counterparts. "hostgssenc" requires either "gss", "trust", or "reject" for its authentication. Similarly, add a "gssencmode" parameter to libpq. Supported values are "disable", "require", and "prefer". Notably, negotiation will only be attempted if credentials can be acquired. Move credential acquisition into its own function to support this behavior. Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring if GSSAPI authentication was used, what principal was used, and if encryption is being used on the connection. Finally, add documentation for everything new, and update existing documentation on connection security. Thanks to Michael Paquier for the Windows fixes. Author: Robbie Harwood, with changes to the read/write functions by me. Reviewed in various forms and at different times by: Michael Paquier, Andres Freund, David Steele. Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com
2019-04-03 21:02:33 +02:00
</para>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<table id="pg-stat-archiver-view" xreflabel="pg_stat_archiver">
<title><structname>pg_stat_archiver</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>archived_count</structfield> <type>bigint</type>
</para>
<para>
Number of WAL files that have been successfully archived
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_archived_wal</structfield> <type>text</type>
</para>
<para>
Fix race condition in 028_pitr_timelines.pl test, add note to docs. The 028_pitr_timelines.pl test would sometimes hang, waiting for a WAL segment that was just filled up to be archived. It was because the test used 'pg_stat_archiver.last_archived_wal' to check if a file was archived, but the order that WAL files are archived when a standby is promoted is not fully deterministic, and 'last_archived_wal' tracks the last segment that was archived, not the highest-numbered WAL segment. Because of that, if the archiver archived segment 3, and then 2, 'last_archived_wal' say 2, and the test query would think that 3 has not been archived yet. Normally, WAL files are marked ready for archival in order, and the archiver process will process them in order, so that issue doesn't arise. We have used the same query on 'last_archived_wal' in a few other tests with no problem. But when a standby is promoted, things are a bit chaotic. After promotion, the server will try to archive all the WAL segments from the old timeline that are in pg_wal, as well as the history file and any new WAL segments on the new timeline. The end-of-recovery checkpoint will create the .ready files for all the WAL files on the old timeline, but at the same time, the new timeline is opened up for business. A file from the new timeline can therefore be archived before the files from the old timeline have been marked as ready for archival. It turns out that we don't really need to wait for the archival in this particular test, because the standby server is about to be stopped, and stopping a server will wait for the end-of-recovery checkpoint and all WAL archivals to finish, anyway. So we can just remove it from the test. Add a note to the docs on 'pg_stat_archiver' view that files can be archived out of order. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/3186114.1644960507@sss.pgh.pa.us
2022-02-16 00:37:48 +01:00
Name of the WAL file most recently successfully archived
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_archived_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Fix race condition in 028_pitr_timelines.pl test, add note to docs. The 028_pitr_timelines.pl test would sometimes hang, waiting for a WAL segment that was just filled up to be archived. It was because the test used 'pg_stat_archiver.last_archived_wal' to check if a file was archived, but the order that WAL files are archived when a standby is promoted is not fully deterministic, and 'last_archived_wal' tracks the last segment that was archived, not the highest-numbered WAL segment. Because of that, if the archiver archived segment 3, and then 2, 'last_archived_wal' say 2, and the test query would think that 3 has not been archived yet. Normally, WAL files are marked ready for archival in order, and the archiver process will process them in order, so that issue doesn't arise. We have used the same query on 'last_archived_wal' in a few other tests with no problem. But when a standby is promoted, things are a bit chaotic. After promotion, the server will try to archive all the WAL segments from the old timeline that are in pg_wal, as well as the history file and any new WAL segments on the new timeline. The end-of-recovery checkpoint will create the .ready files for all the WAL files on the old timeline, but at the same time, the new timeline is opened up for business. A file from the new timeline can therefore be archived before the files from the old timeline have been marked as ready for archival. It turns out that we don't really need to wait for the archival in this particular test, because the standby server is about to be stopped, and stopping a server will wait for the end-of-recovery checkpoint and all WAL archivals to finish, anyway. So we can just remove it from the test. Add a note to the docs on 'pg_stat_archiver' view that files can be archived out of order. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/3186114.1644960507@sss.pgh.pa.us
2022-02-16 00:37:48 +01:00
Time of the most recent successful archive operation
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>failed_count</structfield> <type>bigint</type>
</para>
<para>
Number of failed attempts for archiving WAL files
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_failed_wal</structfield> <type>text</type>
</para>
<para>
Fix race condition in 028_pitr_timelines.pl test, add note to docs. The 028_pitr_timelines.pl test would sometimes hang, waiting for a WAL segment that was just filled up to be archived. It was because the test used 'pg_stat_archiver.last_archived_wal' to check if a file was archived, but the order that WAL files are archived when a standby is promoted is not fully deterministic, and 'last_archived_wal' tracks the last segment that was archived, not the highest-numbered WAL segment. Because of that, if the archiver archived segment 3, and then 2, 'last_archived_wal' say 2, and the test query would think that 3 has not been archived yet. Normally, WAL files are marked ready for archival in order, and the archiver process will process them in order, so that issue doesn't arise. We have used the same query on 'last_archived_wal' in a few other tests with no problem. But when a standby is promoted, things are a bit chaotic. After promotion, the server will try to archive all the WAL segments from the old timeline that are in pg_wal, as well as the history file and any new WAL segments on the new timeline. The end-of-recovery checkpoint will create the .ready files for all the WAL files on the old timeline, but at the same time, the new timeline is opened up for business. A file from the new timeline can therefore be archived before the files from the old timeline have been marked as ready for archival. It turns out that we don't really need to wait for the archival in this particular test, because the standby server is about to be stopped, and stopping a server will wait for the end-of-recovery checkpoint and all WAL archivals to finish, anyway. So we can just remove it from the test. Add a note to the docs on 'pg_stat_archiver' view that files can be archived out of order. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/3186114.1644960507@sss.pgh.pa.us
2022-02-16 00:37:48 +01:00
Name of the WAL file of the most recent failed archival operation
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_failed_time</structfield> <type>timestamp with time zone</type>
</para>
<para>
Fix race condition in 028_pitr_timelines.pl test, add note to docs. The 028_pitr_timelines.pl test would sometimes hang, waiting for a WAL segment that was just filled up to be archived. It was because the test used 'pg_stat_archiver.last_archived_wal' to check if a file was archived, but the order that WAL files are archived when a standby is promoted is not fully deterministic, and 'last_archived_wal' tracks the last segment that was archived, not the highest-numbered WAL segment. Because of that, if the archiver archived segment 3, and then 2, 'last_archived_wal' say 2, and the test query would think that 3 has not been archived yet. Normally, WAL files are marked ready for archival in order, and the archiver process will process them in order, so that issue doesn't arise. We have used the same query on 'last_archived_wal' in a few other tests with no problem. But when a standby is promoted, things are a bit chaotic. After promotion, the server will try to archive all the WAL segments from the old timeline that are in pg_wal, as well as the history file and any new WAL segments on the new timeline. The end-of-recovery checkpoint will create the .ready files for all the WAL files on the old timeline, but at the same time, the new timeline is opened up for business. A file from the new timeline can therefore be archived before the files from the old timeline have been marked as ready for archival. It turns out that we don't really need to wait for the archival in this particular test, because the standby server is about to be stopped, and stopping a server will wait for the end-of-recovery checkpoint and all WAL archivals to finish, anyway. So we can just remove it from the test. Add a note to the docs on 'pg_stat_archiver' view that files can be archived out of order. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/3186114.1644960507@sss.pgh.pa.us
2022-02-16 00:37:48 +01:00
Time of the most recent failed archival operation
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset
</para></entry>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</row>
</tbody>
</tgroup>
</table>
Fix race condition in 028_pitr_timelines.pl test, add note to docs. The 028_pitr_timelines.pl test would sometimes hang, waiting for a WAL segment that was just filled up to be archived. It was because the test used 'pg_stat_archiver.last_archived_wal' to check if a file was archived, but the order that WAL files are archived when a standby is promoted is not fully deterministic, and 'last_archived_wal' tracks the last segment that was archived, not the highest-numbered WAL segment. Because of that, if the archiver archived segment 3, and then 2, 'last_archived_wal' say 2, and the test query would think that 3 has not been archived yet. Normally, WAL files are marked ready for archival in order, and the archiver process will process them in order, so that issue doesn't arise. We have used the same query on 'last_archived_wal' in a few other tests with no problem. But when a standby is promoted, things are a bit chaotic. After promotion, the server will try to archive all the WAL segments from the old timeline that are in pg_wal, as well as the history file and any new WAL segments on the new timeline. The end-of-recovery checkpoint will create the .ready files for all the WAL files on the old timeline, but at the same time, the new timeline is opened up for business. A file from the new timeline can therefore be archived before the files from the old timeline have been marked as ready for archival. It turns out that we don't really need to wait for the archival in this particular test, because the standby server is about to be stopped, and stopping a server will wait for the end-of-recovery checkpoint and all WAL archivals to finish, anyway. So we can just remove it from the test. Add a note to the docs on 'pg_stat_archiver' view that files can be archived out of order. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/3186114.1644960507@sss.pgh.pa.us
2022-02-16 00:37:48 +01:00
<para>
Normally, WAL files are archived in order, oldest to newest, but that is
not guaranteed, and does not hold under special circumstances like when
promoting a standby or after crash recovery. Therefore it is not safe to
assume that all files older than
<structfield>last_archived_wal</structfield> have also been successfully
archived.
</para>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
</sect2>
<sect2 id="monitoring-pg-stat-io-view">
<title><structname>pg_stat_io</structname></title>
<indexterm>
<primary>pg_stat_io</primary>
</indexterm>
<para>
The <structname>pg_stat_io</structname> view will contain one row for each
combination of backend type, target I/O object, and I/O context, showing
cluster-wide I/O statistics. Combinations which do not make sense are
omitted.
</para>
<para>
Currently, I/O on relations (e.g. tables, indexes) is tracked. However,
relation I/O which bypasses shared buffers (e.g. when moving a table from one
tablespace to another) is currently not tracked.
</para>
<table id="pg-stat-io-view" xreflabel="pg_stat_io">
<title><structname>pg_stat_io</structname> View</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
Column Type
</para>
<para>
Description
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>backend_type</structfield> <type>text</type>
</para>
<para>
Type of backend (e.g. background worker, autovacuum worker). See <link
linkend="monitoring-pg-stat-activity-view">
<structname>pg_stat_activity</structname></link> for more information
on <varname>backend_type</varname>s. Some
<varname>backend_type</varname>s do not accumulate I/O operation
statistics and will not be included in the view.
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
<structfield>object</structfield> <type>text</type>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
</para>
<para>
Target object of an I/O operation. Possible values are:
<itemizedlist>
<listitem>
<para>
<literal>relation</literal>: Permanent relations.
</para>
</listitem>
<listitem>
<para>
<literal>temp relation</literal>: Temporary relations.
</para>
</listitem>
</itemizedlist>
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
<structfield>context</structfield> <type>text</type>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
</para>
<para>
The context of an I/O operation. Possible values are:
</para>
<itemizedlist>
<listitem>
<para>
<literal>normal</literal>: The default or standard
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
<varname>context</varname> for a type of I/O operation. For
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
example, by default, relation data is read into and written out from
shared buffers. Thus, reads and writes of relation data to and from
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
shared buffers are tracked in <varname>context</varname>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<literal>normal</literal>.
</para>
</listitem>
<listitem>
<para>
<literal>vacuum</literal>: I/O operations performed outside of shared
buffers while vacuuming and analyzing permanent relations. Temporary
table vacuums use the same local buffer pool as other temporary table
doc: Spell I/O consistently The pg_stat_io and pg_stat_copy_progress view docs spelled "I/O" as "IO" or even "io" in some places when not referring to literal names or string values. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87fry6lx5s.fsf@wibble.ilmari.org
2024-02-06 05:29:22 +01:00
I/O operations and are tracked in <varname>context</varname>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<literal>normal</literal>.
</para>
</listitem>
<listitem>
<para>
<literal>bulkread</literal>: Certain large read I/O operations
done outside of shared buffers, for example, a sequential scan of a
large table.
</para>
</listitem>
<listitem>
<para>
<literal>bulkwrite</literal>: Certain large write I/O operations
done outside of shared buffers, such as <command>COPY</command>.
</para>
</listitem>
</itemizedlist>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>reads</structfield> <type>bigint</type>
</para>
<para>
Number of read operations, each of the size specified in
<varname>op_bytes</varname>.
</para>
</entry>
</row>
Track IO times in pg_stat_io a9c70b46dbe and 8aaa04b32S added counting of IO operations to a new view, pg_stat_io. Now, add IO timing for reads, writes, extends, and fsyncs to pg_stat_io as well. This combines the tracking for pgBufferUsage with the tracking for pg_stat_io into a new function pgstat_count_io_op_time(). This should make it a bit easier to avoid the somewhat costly instr_time conversion done for pgBufferUsage. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/flat/CAAKRu_ay5iKmnbXZ3DsauViF3eMxu4m1oNnJXqV_HyqYeg55Ww%40mail.gmail.com
2023-04-08 01:05:26 +02:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>read_time</structfield> <type>double precision</type>
</para>
<para>
Time spent in read operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
</para>
</entry>
</row>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>writes</structfield> <type>bigint</type>
</para>
<para>
Number of write operations, each of the size specified in
<varname>op_bytes</varname>.
</para>
</entry>
</row>
Track IO times in pg_stat_io a9c70b46dbe and 8aaa04b32S added counting of IO operations to a new view, pg_stat_io. Now, add IO timing for reads, writes, extends, and fsyncs to pg_stat_io as well. This combines the tracking for pgBufferUsage with the tracking for pg_stat_io into a new function pgstat_count_io_op_time(). This should make it a bit easier to avoid the somewhat costly instr_time conversion done for pgBufferUsage. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/flat/CAAKRu_ay5iKmnbXZ3DsauViF3eMxu4m1oNnJXqV_HyqYeg55Ww%40mail.gmail.com
2023-04-08 01:05:26 +02:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>write_time</structfield> <type>double precision</type>
</para>
<para>
Time spent in write operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
</para>
</entry>
</row>
Add writeback to pg_stat_io 28e626bde00 added the concept of IOOps but neglected to include writeback operations. ac8d53dae5 added time spent doing these I/O operations. Without counting writeback, checkpointer write time in the log often differed substantially from that in pg_stat_io. To fix this, add IOOp IOOP_WRITEBACK and track writeback in pg_stat_io. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reported-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20230419172326.dhgyo4wrrhulovt6%40awork3.anarazel.de
2023-05-17 20:18:35 +02:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>writebacks</structfield> <type>bigint</type>
</para>
<para>
Number of units of size <varname>op_bytes</varname> which the process
requested the kernel write out to permanent storage.
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>writeback_time</structfield> <type>double precision</type>
</para>
<para>
Time spent in writeback operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero). This
includes the time spent queueing write-out requests and, potentially,
the time spent to write out the dirty data.
</para>
</entry>
</row>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>extends</structfield> <type>bigint</type>
</para>
<para>
Number of relation extend operations, each of the size specified in
<varname>op_bytes</varname>.
</para>
</entry>
</row>
Track IO times in pg_stat_io a9c70b46dbe and 8aaa04b32S added counting of IO operations to a new view, pg_stat_io. Now, add IO timing for reads, writes, extends, and fsyncs to pg_stat_io as well. This combines the tracking for pgBufferUsage with the tracking for pg_stat_io into a new function pgstat_count_io_op_time(). This should make it a bit easier to avoid the somewhat costly instr_time conversion done for pgBufferUsage. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/flat/CAAKRu_ay5iKmnbXZ3DsauViF3eMxu4m1oNnJXqV_HyqYeg55Ww%40mail.gmail.com
2023-04-08 01:05:26 +02:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>extend_time</structfield> <type>double precision</type>
</para>
<para>
Time spent in extend operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
</para>
</entry>
</row>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>op_bytes</structfield> <type>bigint</type>
</para>
<para>
The number of bytes per unit of I/O read, written, or extended.
</para>
<para>
Relation data reads, writes, and extends are done in
<varname>block_size</varname> units, derived from the build-time
parameter <symbol>BLCKSZ</symbol>, which is <literal>8192</literal> by
default.
</para>
</entry>
</row>
Track shared buffer hits in pg_stat_io Among other things, this should make it easier to calculate a useful cache hit ratio by excluding buffer reads via buffer access strategies. As buffer access strategies reuse buffers (and thus evict the prior buffer contents), it is normal to see reads on repeated scans of the same data. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CAAKRu_beMa9Hzih40%3DXPYqhDVz6tsgUGTrhZXRo%3Dunp%2Bszb%3DUA%40mail.gmail.com
2023-03-31 04:22:40 +02:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>hits</structfield> <type>bigint</type>
</para>
<para>
The number of times a desired block was found in a shared buffer.
</para>
</entry>
</row>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>evictions</structfield> <type>bigint</type>
</para>
<para>
Number of times a block has been written out from a shared or local
buffer in order to make it available for another use.
</para>
<para>
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
In <varname>context</varname> <literal>normal</literal>, this counts
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
the number of times a block was evicted from a buffer and replaced with
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
another block. In <varname>context</varname>s
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<literal>bulkwrite</literal>, <literal>bulkread</literal>, and
<literal>vacuum</literal>, this counts the number of times a block was
evicted from shared buffers in order to add the shared buffer to a
separate, size-limited ring buffer for use in a bulk I/O operation.
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>reuses</structfield> <type>bigint</type>
</para>
<para>
The number of times an existing buffer in a size-limited ring buffer
outside of shared buffers was reused as part of an I/O operation in the
<literal>bulkread</literal>, <literal>bulkwrite</literal>, or
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
<literal>vacuum</literal> <varname>context</varname>s.
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
</para>
</entry>
</row>
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>fsyncs</structfield> <type>bigint</type>
</para>
<para>
Number of <literal>fsync</literal> calls. These are only tracked in
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
<varname>context</varname> <literal>normal</literal>.
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
</para>
</entry>
</row>
Track IO times in pg_stat_io a9c70b46dbe and 8aaa04b32S added counting of IO operations to a new view, pg_stat_io. Now, add IO timing for reads, writes, extends, and fsyncs to pg_stat_io as well. This combines the tracking for pgBufferUsage with the tracking for pg_stat_io into a new function pgstat_count_io_op_time(). This should make it a bit easier to avoid the somewhat costly instr_time conversion done for pgBufferUsage. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/flat/CAAKRu_ay5iKmnbXZ3DsauViF3eMxu4m1oNnJXqV_HyqYeg55Ww%40mail.gmail.com
2023-04-08 01:05:26 +02:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>fsync_time</structfield> <type>double precision</type>
</para>
<para>
Time spent in fsync operations in milliseconds (if
<xref linkend="guc-track-io-timing"/> is enabled, otherwise zero)
</para>
</entry>
</row>
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
<row>
<entry role="catalog_table_entry">
<para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset.
</para>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
Some backend types never perform I/O operations on some I/O objects and/or
in some I/O contexts. These rows are omitted from the view. For example, the
checkpointer does not checkpoint temporary tables, so there will be no rows
for <varname>backend_type</varname> <literal>checkpointer</literal> and
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
<varname>object</varname> <literal>temp relation</literal>.
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
</para>
<para>
In addition, some I/O operations will never be performed either by certain
backend types or on certain I/O objects and/or in certain I/O contexts.
These cells will be NULL. For example, temporary tables are not
<literal>fsync</literal>ed, so <varname>fsyncs</varname> will be NULL for
Remove io prefix from pg_stat_io columns a9c70b46 added the statistics view pg_stat_io which contained columns "io_context" and "io_object". Given that the columns are in the pg_stat_io view, the "io" prefix is somewhat redundant, so remove it. The code variables referring to these fields are kept unchanged so as they can keep their context about I/O. Bump catalog version. Author: Melanie Plageman Reviewed-by: Kyotaro Horiguchi, Fabrízio de Royes Mello Discussion: https://postgr.es/m/CAAKRu_aAQoJWrvT2BYYQvJChFKra_O-5ra3jhzKJZqWsTR1CPQ@mail.gmail.com
2023-04-21 00:21:50 +02:00
<varname>object</varname> <literal>temp relation</literal>. Also, the
Add pg_stat_io view, providing more detailed IO statistics Builds on 28e626bde00 and f30d62c2fc6. See the former for motivation. Rows of the view show IO operations for a particular backend type, IO target object, IO context combination (e.g. a client backend's operations on permanent relations in shared buffers) and each column in the view is the total number of IO Operations done (e.g. writes). So a cell in the view would be, for example, the number of blocks of relation data written from shared buffers by client backends since the last stats reset. In anticipation of tracking WAL IO and non-block-oriented IO (such as temporary file IO), the "op_bytes" column specifies the unit of the "reads", "writes", and "extends" columns for a given row. Rows for combinations of IO operation, backend type, target object and context that never occur, are ommitted entirely. For example, checkpointer will never operate on temporary relations. Similarly, if an IO operation never occurs for such a combination, the IO operation's cell will be null, to distinguish from 0 observed IO operations. For example, bgwriter should not perform reads. Note that some of the cells in the view are redundant with fields in pg_stat_bgwriter (e.g. buffers_backend). For now, these have been kept for backwards compatibility. Bumps catversion. Author: Melanie Plageman <melanieplageman@gmail.com> Author: Samay Sharma <smilingsamay@gmail.com> Reviewed-by: Maciek Sakrejda <m.sakrejda@gmail.com> Reviewed-by: Lukas Fittl <lukas@fittl.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200124195226.lth52iydq2n2uilq@alap3.anarazel.de
2023-02-11 18:51:58 +01:00
background writer does not perform reads, so <varname>reads</varname> will
be NULL in rows for <varname>backend_type</varname> <literal>background
writer</literal>.
</para>
<para>
<structname>pg_stat_io</structname> can be used to inform database tuning.
For example:
<itemizedlist>
<listitem>
<para>
A high <varname>evictions</varname> count can indicate that shared
buffers should be increased.
</para>
</listitem>
<listitem>
<para>
Client backends rely on the checkpointer to ensure data is persisted to
permanent storage. Large numbers of <varname>fsyncs</varname> by
<literal>client backend</literal>s could indicate a misconfiguration of
shared buffers or of the checkpointer. More information on configuring
the checkpointer can be found in <xref linkend="wal-configuration"/>.
</para>
</listitem>
<listitem>
<para>
Normally, client backends should be able to rely on auxiliary processes
like the checkpointer and the background writer to write out dirty data
as much as possible. Large numbers of writes by client backends could
indicate a misconfiguration of shared buffers or of the checkpointer.
More information on configuring the checkpointer can be found in <xref
linkend="wal-configuration"/>.
</para>
</listitem>
</itemizedlist>
</para>
Track IO times in pg_stat_io a9c70b46dbe and 8aaa04b32S added counting of IO operations to a new view, pg_stat_io. Now, add IO timing for reads, writes, extends, and fsyncs to pg_stat_io as well. This combines the tracking for pgBufferUsage with the tracking for pg_stat_io into a new function pgstat_count_io_op_time(). This should make it a bit easier to avoid the somewhat costly instr_time conversion done for pgBufferUsage. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/flat/CAAKRu_ay5iKmnbXZ3DsauViF3eMxu4m1oNnJXqV_HyqYeg55Ww%40mail.gmail.com
2023-04-08 01:05:26 +02:00
<note>
<para>
Columns tracking I/O time will only be non-zero when
<xref linkend="guc-track-io-timing"/> is enabled. The user should be
careful when referencing these columns in combination with their
doc: Spell I/O consistently The pg_stat_io and pg_stat_copy_progress view docs spelled "I/O" as "IO" or even "io" in some places when not referring to literal names or string values. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87fry6lx5s.fsf@wibble.ilmari.org
2024-02-06 05:29:22 +01:00
corresponding I/O operations in case <varname>track_io_timing</varname>
Track IO times in pg_stat_io a9c70b46dbe and 8aaa04b32S added counting of IO operations to a new view, pg_stat_io. Now, add IO timing for reads, writes, extends, and fsyncs to pg_stat_io as well. This combines the tracking for pgBufferUsage with the tracking for pg_stat_io into a new function pgstat_count_io_op_time(). This should make it a bit easier to avoid the somewhat costly instr_time conversion done for pgBufferUsage. Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Discussion: https://postgr.es/m/flat/CAAKRu_ay5iKmnbXZ3DsauViF3eMxu4m1oNnJXqV_HyqYeg55Ww%40mail.gmail.com
2023-04-08 01:05:26 +02:00
was not enabled for the entire time since the last stats reset.
</para>
</note>
Fix race condition in 028_pitr_timelines.pl test, add note to docs. The 028_pitr_timelines.pl test would sometimes hang, waiting for a WAL segment that was just filled up to be archived. It was because the test used 'pg_stat_archiver.last_archived_wal' to check if a file was archived, but the order that WAL files are archived when a standby is promoted is not fully deterministic, and 'last_archived_wal' tracks the last segment that was archived, not the highest-numbered WAL segment. Because of that, if the archiver archived segment 3, and then 2, 'last_archived_wal' say 2, and the test query would think that 3 has not been archived yet. Normally, WAL files are marked ready for archival in order, and the archiver process will process them in order, so that issue doesn't arise. We have used the same query on 'last_archived_wal' in a few other tests with no problem. But when a standby is promoted, things are a bit chaotic. After promotion, the server will try to archive all the WAL segments from the old timeline that are in pg_wal, as well as the history file and any new WAL segments on the new timeline. The end-of-recovery checkpoint will create the .ready files for all the WAL files on the old timeline, but at the same time, the new timeline is opened up for business. A file from the new timeline can therefore be archived before the files from the old timeline have been marked as ready for archival. It turns out that we don't really need to wait for the archival in this particular test, because the standby server is about to be stopped, and stopping a server will wait for the end-of-recovery checkpoint and all WAL archivals to finish, anyway. So we can just remove it from the test. Add a note to the docs on 'pg_stat_archiver' view that files can be archived out of order. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/3186114.1644960507@sss.pgh.pa.us
2022-02-16 00:37:48 +01:00
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-bgwriter-view">
<title><structname>pg_stat_bgwriter</structname></title>
<indexterm>
<primary>pg_stat_bgwriter</primary>
</indexterm>
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_bgwriter</structname> view will always have a
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
single row, containing data about the background writer of the cluster.
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
</para>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<table id="pg-stat-bgwriter-view" xreflabel="pg_stat_bgwriter">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_stat_bgwriter</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<structfield>buffers_clean</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Number of buffers written by the background writer
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<structfield>maxwritten_clean</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Number of times the background writer stopped a cleaning
scan because it had written too many buffers
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Publish checkpoint timing information to pg_stat_bgwriter. Greg Smith, Peter Geoghegan, and Robert Haas
2012-04-05 20:03:21 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<structfield>buffers_alloc</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Number of buffers allocated
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Publish checkpoint timing information to pg_stat_bgwriter. Greg Smith, Peter Geoghegan, and Robert Haas
2012-04-05 20:03:21 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Publish checkpoint timing information to pg_stat_bgwriter. Greg Smith, Peter Geoghegan, and Robert Haas
2012-04-05 20:03:21 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Time at which these statistics were last reset
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Publish checkpoint timing information to pg_stat_bgwriter. Greg Smith, Peter Geoghegan, and Robert Haas
2012-04-05 20:03:21 +02:00
</row>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
</tbody>
</tgroup>
</table>
</sect2>
<sect2 id="monitoring-pg-stat-checkpointer-view">
<title><structname>pg_stat_checkpointer</structname></title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<indexterm>
<primary>pg_stat_checkpointer</primary>
</indexterm>
<para>
The <structname>pg_stat_checkpointer</structname> view will always have a
single row, containing data about the checkpointer process of the cluster.
</para>
<table id="pg-stat-checkpointer-view" xreflabel="pg_stat_checkpointer">
<title><structname>pg_stat_checkpointer</structname> View</title>
<tgroup cols="1">
<thead>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Column Type
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Description
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<structfield>num_timed</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Number of scheduled checkpoints that have been performed
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<structfield>num_requested</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Number of requested checkpoints that have been performed
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Enhance checkpointer restartpoint statistics Bhis commit introduces enhancements to the pg_stat_checkpointer view by adding three new columns: restartpoints_timed, restartpoints_req, and restartpoints_done. These additions aim to improve the visibility and monitoring of restartpoint processes on replicas. Previously, it was challenging to differentiate between successful and failed restartpoint requests. This limitation arises because restartpoints on replicas are dependent on checkpoint records from the primary, and cannot occur more frequently than these checkpoints. The new columns allow for clear distinction and tracking of restartpoint requests, their triggers, and successful completions. This enhancement aids database administrators and developers in better understanding and diagnosing issues related to restartpoint behavior, particularly in scenarios where restartpoint requests may fail. System catalog is changed. Catversion is bumped. Discussion: https://postgr.es/m/99b2ccd1-a77a-962a-0837-191cdf56c2b9%40inbox.ru Author: Anton A. Melnikov Reviewed-by: Kyotaro Horiguchi, Alexander Korotkov
2023-12-24 23:52:42 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>restartpoints_timed</structfield> <type>bigint</type>
</para>
<para>
Number of scheduled restartpoints due to timeout or after a failed attempt to perform it
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>restartpoints_req</structfield> <type>bigint</type>
</para>
<para>
Number of requested restartpoints
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>restartpoints_done</structfield> <type>bigint</type>
</para>
<para>
Number of restartpoints that have been performed
</para></entry>
</row>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
<structfield>write_time</structfield> <type>double precision</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
Total amount of time that has been spent in the portion of
Improve documentation for pg_stat_checkpointer fields pg_stat_checkpointer contains statistics for checkpoints and restartpoints. Before 12915a58eec9 documentation said only about checkpoints implying that restartpoint is the variation of checkpoint. 12915a58eec9 introduced new separate statistics fields for restartpoints. This commit explicitly documents fields that are relevant for both checkpoints and restartpoints. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevExav5-SR0x%2BG9kBUMV0G8XsvSUfuyyqmYBBJi6VHns6sw%40mail.gmail.com Reviewed-by: Anton A. Melnikov
2024-03-14 01:07:27 +01:00
processing checkpoints and restartpoints where files are written to disk,
in milliseconds
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sync_time</structfield> <type>double precision</type>
</para>
<para>
Total amount of time that has been spent in the portion of
Improve documentation for pg_stat_checkpointer fields pg_stat_checkpointer contains statistics for checkpoints and restartpoints. Before 12915a58eec9 documentation said only about checkpoints implying that restartpoint is the variation of checkpoint. 12915a58eec9 introduced new separate statistics fields for restartpoints. This commit explicitly documents fields that are relevant for both checkpoints and restartpoints. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevExav5-SR0x%2BG9kBUMV0G8XsvSUfuyyqmYBBJi6VHns6sw%40mail.gmail.com Reviewed-by: Anton A. Melnikov
2024-03-14 01:07:27 +01:00
processing checkpoints and restartpoints where files are synchronized to
disk, in milliseconds
Introduce pg_stat_checkpointer Historically, the statistics of the checkpointer have been always part of pg_stat_bgwriter. This commit removes a few columns from pg_stat_bgwriter, and introduces pg_stat_checkpointer with equivalent, renamed columns (plus a new one for the reset timestamp): - checkpoints_timed -> num_timed - checkpoints_req -> num_requested - checkpoint_write_time -> write_time - checkpoint_sync_time -> sync_time - buffers_checkpoint -> buffers_written The fields of PgStat_CheckpointerStats and its SQL functions are renamed to match with the new field names, for consistency. Note that background writer and checkpointer have been split into two different processes in commits 806a2aee3791 and bf405ba8e460. The pgstat structures were already split, making this change straight-forward. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Bertrand Drouvot, Andres Freund, Michael Paquier Discussion: https://postgr.es/m/CALj2ACVxX2ii=66RypXRweZe2EsBRiPMj0aHfRfHUeXJcC7kHg@mail.gmail.com
2023-10-30 01:47:16 +01:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>buffers_written</structfield> <type>bigint</type>
</para>
<para>
Improve documentation for pg_stat_checkpointer fields pg_stat_checkpointer contains statistics for checkpoints and restartpoints. Before 12915a58eec9 documentation said only about checkpoints implying that restartpoint is the variation of checkpoint. 12915a58eec9 introduced new separate statistics fields for restartpoints. This commit explicitly documents fields that are relevant for both checkpoints and restartpoints. Reported-by: Magnus Hagander Discussion: https://postgr.es/m/CABUevExav5-SR0x%2BG9kBUMV0G8XsvSUfuyyqmYBBJi6VHns6sw%40mail.gmail.com Reviewed-by: Anton A. Melnikov
2024-03-14 01:07:27 +01:00
Number of buffers written during checkpoints and restartpoints
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</tbody>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</tgroup>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
Add pg_stat_wal statistics view. This view shows the statistics about WAL activity. Currently it has only two columns: wal_buffers_full and stats_reset. wal_buffers_full column indicates the number of times WAL data was written to the disk because WAL buffers got full. This information is useful when tuning wal_buffers. stats_reset column indicates the time at which these statistics were last reset. pg_stat_wal view is also the basic infrastructure to expose other various statistics about WAL activity later. Bump PGSTAT_FILE_FORMAT_ID due to the change in pgstat format. Bump catalog version. Author: Masahiro Ikeda Reviewed-by: Takayuki Tsunakawa, Kyotaro Horiguchi, Amit Kapila, Fujii Masao Discussion: https://postgr.es/m/188bd3f2d2233cf97753b5ced02bb050@oss.nttdata.com
2020-10-02 03:17:11 +02:00
<sect2 id="monitoring-pg-stat-wal-view">
<title><structname>pg_stat_wal</structname></title>
<indexterm>
<primary>pg_stat_wal</primary>
</indexterm>
<para>
The <structname>pg_stat_wal</structname> view will always have a
single row, containing data about WAL activity of the cluster.
</para>
<table id="pg-stat-wal-view" xreflabel="pg_stat_wal">
<title><structname>pg_stat_wal</structname> View</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Track total number of WAL records, FPIs and bytes generated in the cluster. Commit 6b466bf5f2 allowed pg_stat_statements to track the number of WAL records, full page images and bytes that each statement generated. Similarly this commit allows us to track the cluster-wide WAL statistics counters. New columns wal_records, wal_fpi and wal_bytes are added into the pg_stat_wal view, and reports the total number of WAL records, full page images and bytes generated in the , respectively. Author: Masahiro Ikeda Reviewed-by: Amit Kapila, Movead Li, Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/35ef960128b90bfae3b3fdf60a3a860f@oss.nttdata.com
2020-12-02 05:00:15 +01:00
<structfield>wal_records</structfield> <type>bigint</type>
</para>
<para>
Total number of WAL records generated
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wal_fpi</structfield> <type>bigint</type>
</para>
<para>
Total number of WAL full page images generated
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wal_bytes</structfield> <type>numeric</type>
</para>
<para>
Fix typos and grammar in docs and comments This fixes several areas of the documentation and some comments in matters of style, grammar, or even format. Author: Justin Pryzby Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2020-12-24 09:05:49 +01:00
Total amount of WAL generated in bytes
Track total number of WAL records, FPIs and bytes generated in the cluster. Commit 6b466bf5f2 allowed pg_stat_statements to track the number of WAL records, full page images and bytes that each statement generated. Similarly this commit allows us to track the cluster-wide WAL statistics counters. New columns wal_records, wal_fpi and wal_bytes are added into the pg_stat_wal view, and reports the total number of WAL records, full page images and bytes generated in the , respectively. Author: Masahiro Ikeda Reviewed-by: Amit Kapila, Movead Li, Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/35ef960128b90bfae3b3fdf60a3a860f@oss.nttdata.com
2020-12-02 05:00:15 +01:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Add pg_stat_wal statistics view. This view shows the statistics about WAL activity. Currently it has only two columns: wal_buffers_full and stats_reset. wal_buffers_full column indicates the number of times WAL data was written to the disk because WAL buffers got full. This information is useful when tuning wal_buffers. stats_reset column indicates the time at which these statistics were last reset. pg_stat_wal view is also the basic infrastructure to expose other various statistics about WAL activity later. Bump PGSTAT_FILE_FORMAT_ID due to the change in pgstat format. Bump catalog version. Author: Masahiro Ikeda Reviewed-by: Takayuki Tsunakawa, Kyotaro Horiguchi, Amit Kapila, Fujii Masao Discussion: https://postgr.es/m/188bd3f2d2233cf97753b5ced02bb050@oss.nttdata.com
2020-10-02 03:17:11 +02:00
<structfield>wal_buffers_full</structfield> <type>bigint</type>
</para>
<para>
Fix typos and grammar in docs and comments This fixes several areas of the documentation and some comments in matters of style, grammar, or even format. Author: Justin Pryzby Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2020-12-24 09:05:49 +01:00
Number of times WAL data was written to disk because WAL buffers became full
Add pg_stat_wal statistics view. This view shows the statistics about WAL activity. Currently it has only two columns: wal_buffers_full and stats_reset. wal_buffers_full column indicates the number of times WAL data was written to the disk because WAL buffers got full. This information is useful when tuning wal_buffers. stats_reset column indicates the time at which these statistics were last reset. pg_stat_wal view is also the basic infrastructure to expose other various statistics about WAL activity later. Bump PGSTAT_FILE_FORMAT_ID due to the change in pgstat format. Bump catalog version. Author: Masahiro Ikeda Reviewed-by: Takayuki Tsunakawa, Kyotaro Horiguchi, Amit Kapila, Fujii Masao Discussion: https://postgr.es/m/188bd3f2d2233cf97753b5ced02bb050@oss.nttdata.com
2020-10-02 03:17:11 +02:00
</para></entry>
</row>
Track total amounts of times spent writing and syncing WAL data to disk. This commit adds new GUC track_wal_io_timing. When this is enabled, the total amounts of time XLogWrite writes and issue_xlog_fsync syncs WAL data to disk are counted in pg_stat_wal. This information would be useful to check how much WAL write and sync affect the performance. Enabling track_wal_io_timing will make the server query the operating system for the current time every time WAL is written or synced, which may cause significant overhead on some platforms. To avoid such additional overhead in the server with track_io_timing enabled, this commit introduces track_wal_io_timing as a separate parameter from track_io_timing. Note that WAL write and sync activity by walreceiver has not been tracked yet. This commit makes the server also track the numbers of times XLogWrite writes and issue_xlog_fsync syncs WAL data to disk, in pg_stat_wal, regardless of the setting of track_wal_io_timing. This counters can be used to calculate the WAL write and sync time per request, for example. Bump PGSTAT_FILE_FORMAT_ID. Bump catalog version. Author: Masahiro Ikeda Reviewed-By: Japin Li, Hayato Kuroda, Masahiko Sawada, David Johnston, Fujii Masao Discussion: https://postgr.es/m/0509ad67b585a5b86a83d445dfa75392@oss.nttdata.com
2021-03-09 08:52:06 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wal_write</structfield> <type>bigint</type>
</para>
<para>
Number of times WAL buffers were written out to disk via
<function>XLogWrite</function> request.
See <xref linkend="wal-configuration"/> for more information about
the internal WAL function <function>XLogWrite</function>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wal_sync</structfield> <type>bigint</type>
</para>
<para>
Number of times WAL files were synced to disk via
<function>issue_xlog_fsync</function> request
(if <xref linkend="guc-fsync"/> is <literal>on</literal> and
<xref linkend="guc-wal-sync-method"/> is either
<literal>fdatasync</literal>, <literal>fsync</literal> or
<literal>fsync_writethrough</literal>, otherwise zero).
See <xref linkend="wal-configuration"/> for more information about
the internal WAL function <function>issue_xlog_fsync</function>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wal_write_time</structfield> <type>double precision</type>
</para>
<para>
Total amount of time spent writing WAL buffers to disk via
<function>XLogWrite</function> request, in milliseconds
(if <xref linkend="guc-track-wal-io-timing"/> is enabled,
otherwise zero). This includes the sync time when
<varname>wal_sync_method</varname> is either
<literal>open_datasync</literal> or <literal>open_sync</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>wal_sync_time</structfield> <type>double precision</type>
</para>
<para>
Total amount of time spent syncing WAL files to disk via
<function>issue_xlog_fsync</function> request, in milliseconds
(if <varname>track_wal_io_timing</varname> is enabled,
<varname>fsync</varname> is <literal>on</literal>, and
<varname>wal_sync_method</varname> is either
<literal>fdatasync</literal>, <literal>fsync</literal> or
<literal>fsync_writethrough</literal>, otherwise zero).
</para></entry>
</row>
Add pg_stat_wal statistics view. This view shows the statistics about WAL activity. Currently it has only two columns: wal_buffers_full and stats_reset. wal_buffers_full column indicates the number of times WAL data was written to the disk because WAL buffers got full. This information is useful when tuning wal_buffers. stats_reset column indicates the time at which these statistics were last reset. pg_stat_wal view is also the basic infrastructure to expose other various statistics about WAL activity later. Bump PGSTAT_FILE_FORMAT_ID due to the change in pgstat format. Bump catalog version. Author: Masahiro Ikeda Reviewed-by: Takayuki Tsunakawa, Kyotaro Horiguchi, Amit Kapila, Fujii Masao Discussion: https://postgr.es/m/188bd3f2d2233cf97753b5ced02bb050@oss.nttdata.com
2020-10-02 03:17:11 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset
</para></entry>
</row>
</tbody>
</tgroup>
</table>
</sect2>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<sect2 id="monitoring-pg-stat-database-view">
<title><structname>pg_stat_database</structname></title>
<indexterm>
<primary>pg_stat_database</primary>
</indexterm>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_database</structname> view will contain one row
for each database in the cluster, plus one for shared objects, showing
database-wide statistics.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</para>
<table id="pg-stat-database-view" xreflabel="pg_stat_database">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_stat_database</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of this database, or 0 for objects belonging to a shared
relation
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of this database, or <literal>NULL</literal> for shared
objects.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>numbackends</structfield> <type>integer</type>
</para>
<para>
Number of backends currently connected to this database, or
<literal>NULL</literal> for shared objects. This is the only column
in this view that returns a value reflecting current state; all other
columns return the accumulated values since the last reset.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>xact_commit</structfield> <type>bigint</type>
</para>
<para>
Number of transactions in this database that have been
committed
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>xact_rollback</structfield> <type>bigint</type>
</para>
<para>
Number of transactions in this database that have been
rolled back
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read in this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of times disk blocks were found already in the buffer
cache, so that a read was not necessary (this only includes hits in the
PostgreSQL buffer cache, not the operating system's file system cache)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tup_returned</structfield> <type>bigint</type>
</para>
<para>
doc: Improve descriptions of tup_returned and tup_fetched in pg_stat_database Previously the descriptions of tup_returned and tup_fetched columns in pg_stat_database view were confusing. This commit improves them so that they represent the following formulas of those columns more accurately. * pg_stat_database.tup_returned = sum(pg_stat_all_tables.seq_tup_read) + sum(pg_stat_all_indexes.idx_tup_read) * pg_stat_database.tup_fetched = sum(pg_stat_all_tables.idx_tup_fetch) In these formulas, note that the counters for some system catalogs like pg_database shared across all databases of a cluster are excluded from the calculations of sum. Author: Masahiro Ikeda Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/9eeeccdb-5dd7-90f9-2807-a4b5d2b76ca3@oss.nttdata.com
2021-06-30 13:57:07 +02:00
Number of live rows fetched by sequential scans and index entries returned by index scans in this database
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tup_fetched</structfield> <type>bigint</type>
</para>
<para>
doc: Improve descriptions of tup_returned and tup_fetched in pg_stat_database Previously the descriptions of tup_returned and tup_fetched columns in pg_stat_database view were confusing. This commit improves them so that they represent the following formulas of those columns more accurately. * pg_stat_database.tup_returned = sum(pg_stat_all_tables.seq_tup_read) + sum(pg_stat_all_indexes.idx_tup_read) * pg_stat_database.tup_fetched = sum(pg_stat_all_tables.idx_tup_fetch) In these formulas, note that the counters for some system catalogs like pg_database shared across all databases of a cluster are excluded from the calculations of sum. Author: Masahiro Ikeda Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/9eeeccdb-5dd7-90f9-2807-a4b5d2b76ca3@oss.nttdata.com
2021-06-30 13:57:07 +02:00
Number of live rows fetched by index scans in this database
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tup_inserted</structfield> <type>bigint</type>
</para>
<para>
Number of rows inserted by queries in this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tup_updated</structfield> <type>bigint</type>
</para>
<para>
Number of rows updated by queries in this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tup_deleted</structfield> <type>bigint</type>
</para>
<para>
Number of rows deleted by queries in this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>conflicts</structfield> <type>bigint</type>
</para>
<para>
Number of queries canceled due to conflicts with recovery
in this database. (Conflicts occur only on standby servers; see
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<link linkend="monitoring-pg-stat-database-conflicts-view">
<structname>pg_stat_database_conflicts</structname></link> for details.)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>temp_files</structfield> <type>bigint</type>
</para>
<para>
Number of temporary files created by queries in this database.
All temporary files are counted, regardless of why the temporary file
was created (e.g., sorting or hashing), and regardless of the
<xref linkend="guc-log-temp-files"/> setting.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>temp_bytes</structfield> <type>bigint</type>
</para>
<para>
Total amount of data written to temporary files by queries in
this database. All temporary files are counted, regardless of why
the temporary file was created, and
regardless of the <xref linkend="guc-log-temp-files"/> setting.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>deadlocks</structfield> <type>bigint</type>
</para>
<para>
Number of deadlocks detected in this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>checksum_failures</structfield> <type>bigint</type>
</para>
<para>
Number of data page checksum failures detected in this
database (or on a shared object), or NULL if data checksums are not
enabled.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>checksum_last_failure</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which the last data page checksum failure was detected in
this database (or on a shared object), or NULL if data checksums are not
enabled.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blk_read_time</structfield> <type>double precision</type>
</para>
<para>
Time spent reading data file blocks by backends in this database,
doc: Add note about I/O timing information in EXPLAIN and pg_stat_database. Explain that the followings are tracked only when track_io_timing GUC is enabled. - blk_read_time and blk_write_time in pg_stat_database - time spent reading and writing data file blocks in EXPLAIN output with BUFFERS option Whther track_io_timing is enabled affects also blk_read_time and blk_write_time in pg_stat_statements, but which was already documented. Author: Atsushi Torikoshi Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CACZ0uYHo_NwbxpLH76OGF-O=13tkR0ZM0zeyGEhZ+JEXZVRyCA@mail.gmail.com
2020-05-22 16:33:58 +02:00
in milliseconds (if <xref linkend="guc-track-io-timing"/> is enabled,
otherwise zero)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blk_write_time</structfield> <type>double precision</type>
</para>
<para>
Time spent writing data file blocks by backends in this database,
doc: Add note about I/O timing information in EXPLAIN and pg_stat_database. Explain that the followings are tracked only when track_io_timing GUC is enabled. - blk_read_time and blk_write_time in pg_stat_database - time spent reading and writing data file blocks in EXPLAIN output with BUFFERS option Whther track_io_timing is enabled affects also blk_read_time and blk_write_time in pg_stat_statements, but which was already documented. Author: Atsushi Torikoshi Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CACZ0uYHo_NwbxpLH76OGF-O=13tkR0ZM0zeyGEhZ+JEXZVRyCA@mail.gmail.com
2020-05-22 16:33:58 +02:00
in milliseconds (if <xref linkend="guc-track-io-timing"/> is enabled,
otherwise zero)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
Add pg_stat_database counters for sessions and session time This add counters for number of sessions, the different kind of session termination types, and timers for how much time is spent in active vs idle in a database to pg_stat_database. Internally this also renames the parameter "force" to disconnect. This was the only use-case for the parameter before, so repurposing it to this mroe narrow usecase makes things cleaner than inventing something new. Author: Laurenz Albe Reviewed-By: Magnus Hagander, Soumyadeep Chakraborty, Masahiro Ikeda Discussion: https://postgr.es/m/b07e1f9953701b90c66ed368656f2aef40cac4fb.camel@cybertec.at
2021-01-17 13:34:09 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>session_time</structfield> <type>double precision</type>
</para>
<para>
Time spent by database sessions in this database, in milliseconds
(note that statistics are only updated when the state of a session
changes, so if sessions have been idle for a long time, this idle time
won't be included)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>active_time</structfield> <type>double precision</type>
</para>
<para>
Time spent executing SQL statements in this database, in milliseconds
(this corresponds to the states <literal>active</literal> and
<literal>fastpath function call</literal> in
<link linkend="monitoring-pg-stat-activity-view">
<structname>pg_stat_activity</structname></link>)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idle_in_transaction_time</structfield> <type>double precision</type>
</para>
<para>
Time spent idling while in a transaction in this database, in milliseconds
(this corresponds to the states <literal>idle in transaction</literal> and
<literal>idle in transaction (aborted)</literal> in
<link linkend="monitoring-pg-stat-activity-view">
<structname>pg_stat_activity</structname></link>)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sessions</structfield> <type>bigint</type>
</para>
<para>
Total number of sessions established to this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sessions_abandoned</structfield> <type>bigint</type>
</para>
<para>
Number of database sessions to this database that were terminated
because connection to the client was lost
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sessions_fatal</structfield> <type>bigint</type>
</para>
<para>
Number of database sessions to this database that were terminated
by fatal errors
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sessions_killed</structfield> <type>bigint</type>
</para>
<para>
Number of database sessions to this database that were terminated
by operator intervention
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset
</para></entry>
</row>
</tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-database-conflicts-view">
<title><structname>pg_stat_database_conflicts</structname></title>
<indexterm>
<primary>pg_stat_database_conflicts</primary>
</indexterm>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_database_conflicts</structname> view will contain
one row per database, showing database-wide statistics about
query cancels occurring due to conflicts with recovery on standby servers.
This view will only contain information on standby servers, since
docs: replace 'master' with 'primary' where appropriate. Also changed "in the primary" to "on the primary", and added a few "the" before "primary". Author: Andres Freund Reviewed-By: David Steele Discussion: https://postgr.es/m/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
2020-06-15 19:12:58 +02:00
conflicts do not occur on primary servers.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</para>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<table id="pg-stat-database-conflicts-view" xreflabel="pg_stat_database_conflicts">
<title><structname>pg_stat_database_conflicts</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of a database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of this database
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confl_tablespace</structfield> <type>bigint</type>
</para>
<para>
Number of queries in this database that have been canceled due to
dropped tablespaces
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confl_lock</structfield> <type>bigint</type>
</para>
<para>
Number of queries in this database that have been canceled due to
lock timeouts
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confl_snapshot</structfield> <type>bigint</type>
</para>
<para>
Number of queries in this database that have been canceled due to
old snapshots
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confl_bufferpin</structfield> <type>bigint</type>
</para>
<para>
Number of queries in this database that have been canceled due to
pinned buffers
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confl_deadlock</structfield> <type>bigint</type>
</para>
<para>
Number of queries in this database that have been canceled due to
deadlocks
</para></entry>
</row>
Handle logical slot conflicts on standby During WAL replay on the standby, when a conflict with a logical slot is identified, invalidate such slots. There are two sources of conflicts: 1) Using the information added in 6af1793954e, logical slots are invalidated if required rows are removed 2) wal_level on the primary server is reduced to below logical Uses the infrastructure introduced in the prior commit. FIXME: add commit reference. Change InvalidatePossiblyObsoleteSlot() to use a recovery conflict to interrupt use of a slot, if called in the startup process. The new recovery conflict is added to pg_stat_database_conflicts, as confl_active_logicalslot. See 6af1793954e for an overall design of logical decoding on a standby. Bumps catversion for the addition of the pg_stat_database_conflicts column. Bumps PGSTAT_FILE_FORMAT_ID for the same reason. Author: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Author: Andres Freund <andres@anarazel.de> Author: Amit Khandekar <amitdkhan.pg@gmail.com> (in an older version) Reviewed-by: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Fabrízio de Royes Mello <fabriziomello@gmail.com> Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/20230407075009.igg7be27ha2htkbt@awork3.anarazel.de
2023-04-08 08:11:28 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>confl_active_logicalslot</structfield> <type>bigint</type>
</para>
<para>
Number of uses of logical slots in this database that have been
doc: Fix some grammar for logical decoding description and functions This documentation is has been added for the support of logical decoding on standbys. Some markups were missing, hence add some where required. Author: Thom Brown Reviewed-by: Justin Pryzby, Daniel Gustafsson Discussion: https://postgr.es/m/CAA-aLv7xCZ0nBJa-NWe0rxBB28TjFjS2JtjiZMoQ+0wsugG+hQ@mail.gmail.com
2023-04-14 06:08:02 +02:00
canceled due to old snapshots or too low a <xref linkend="guc-wal-level"/>
Handle logical slot conflicts on standby During WAL replay on the standby, when a conflict with a logical slot is identified, invalidate such slots. There are two sources of conflicts: 1) Using the information added in 6af1793954e, logical slots are invalidated if required rows are removed 2) wal_level on the primary server is reduced to below logical Uses the infrastructure introduced in the prior commit. FIXME: add commit reference. Change InvalidatePossiblyObsoleteSlot() to use a recovery conflict to interrupt use of a slot, if called in the startup process. The new recovery conflict is added to pg_stat_database_conflicts, as confl_active_logicalslot. See 6af1793954e for an overall design of logical decoding on a standby. Bumps catversion for the addition of the pg_stat_database_conflicts column. Bumps PGSTAT_FILE_FORMAT_ID for the same reason. Author: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Author: Andres Freund <andres@anarazel.de> Author: Amit Khandekar <amitdkhan.pg@gmail.com> (in an older version) Reviewed-by: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Fabrízio de Royes Mello <fabriziomello@gmail.com> Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Reviewed-by: Amit Kapila <amit.kapila16@gmail.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/20230407075009.igg7be27ha2htkbt@awork3.anarazel.de
2023-04-08 08:11:28 +02:00
on the primary
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</tbody>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-all-tables-view">
<title><structname>pg_stat_all_tables</structname></title>
<indexterm>
<primary>pg_stat_all_tables</primary>
</indexterm>
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_all_tables</structname> view will contain
one row for each table in the current database (including TOAST
tables), showing statistics about accesses to that specific table. The
<structname>pg_stat_user_tables</structname> and
<structname>pg_stat_sys_tables</structname> views
contain the same information,
but filtered to only show user and system tables respectively.
Restructure doc sections about statistics views Break out the "dynamic statistics" views in the table from the "collected statistics" ones. Could do with some more refactoring, but this is a start.
2014-11-16 13:47:44 +01:00
</para>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<table id="pg-stat-all-tables-view" xreflabel="pg_stat_all_tables">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_stat_all_tables</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of a table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
</para>
<para>
Name of the schema that this table is in
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relname</structfield> <type>name</type>
</para>
<para>
Name of this table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seq_scan</structfield> <type>bigint</type>
</para>
<para>
Number of sequential scans initiated on this table
</para></entry>
</row>
pgstat: Track time of the last scan of a relation It can be useful to know when a relation has last been used, e.g., when evaluating whether an index is still required. It was already possible to infer the time of the last usage by tracking, e.g., pg_stat_all_indexes.idx_scan over time. But far from everybody does so. To make it easier to detect the last time a relation has been scanned, track that time in each relation's pgstat entry. To minimize overhead a) the timestamp is updated only when the backend pending stats entry is flushed to shared stats b) the last transaction's stop timestamp is used as the timestamp. Bumps catalog and stats format versions. Author: Dave Page <dpage@pgadmin.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bruce Momjian <bruce@momjian.us> Reviewed-by: Vik Fearing <vik@postgresfriends.org> Discussion: https://postgr.es/m/CA+OCxozrVHNFVEPkweUHMZje+t1tfY816d9MZYc6eZwOOusOaQ@mail.gmail.com
2022-10-14 20:11:34 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Doc: unify use of timestamp with time zone vs timestamptz For pg_stat_all_tables, last_vacuum, last_autovacuum and co all used the full "timestamp with time zone" type name. For consistency, make the newly added "last_seq_scan" also use the full type name instead of "timestamptz". Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/DM4PR84MB17348EA11FA90A9BE896AF89EE489%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
2023-06-05 07:34:27 +02:00
<structfield>last_seq_scan</structfield> <type>timestamp with time zone</type>
pgstat: Track time of the last scan of a relation It can be useful to know when a relation has last been used, e.g., when evaluating whether an index is still required. It was already possible to infer the time of the last usage by tracking, e.g., pg_stat_all_indexes.idx_scan over time. But far from everybody does so. To make it easier to detect the last time a relation has been scanned, track that time in each relation's pgstat entry. To minimize overhead a) the timestamp is updated only when the backend pending stats entry is flushed to shared stats b) the last transaction's stop timestamp is used as the timestamp. Bumps catalog and stats format versions. Author: Dave Page <dpage@pgadmin.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bruce Momjian <bruce@momjian.us> Reviewed-by: Vik Fearing <vik@postgresfriends.org> Discussion: https://postgr.es/m/CA+OCxozrVHNFVEPkweUHMZje+t1tfY816d9MZYc6eZwOOusOaQ@mail.gmail.com
2022-10-14 20:11:34 +02:00
</para>
<para>
The time of the last sequential scan on this table, based on the
most recent transaction stop time
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>seq_tup_read</structfield> <type>bigint</type>
</para>
<para>
Number of live rows fetched by sequential scans
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_scan</structfield> <type>bigint</type>
</para>
<para>
Number of index scans initiated on this table
</para></entry>
</row>
pgstat: Track time of the last scan of a relation It can be useful to know when a relation has last been used, e.g., when evaluating whether an index is still required. It was already possible to infer the time of the last usage by tracking, e.g., pg_stat_all_indexes.idx_scan over time. But far from everybody does so. To make it easier to detect the last time a relation has been scanned, track that time in each relation's pgstat entry. To minimize overhead a) the timestamp is updated only when the backend pending stats entry is flushed to shared stats b) the last transaction's stop timestamp is used as the timestamp. Bumps catalog and stats format versions. Author: Dave Page <dpage@pgadmin.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bruce Momjian <bruce@momjian.us> Reviewed-by: Vik Fearing <vik@postgresfriends.org> Discussion: https://postgr.es/m/CA+OCxozrVHNFVEPkweUHMZje+t1tfY816d9MZYc6eZwOOusOaQ@mail.gmail.com
2022-10-14 20:11:34 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Doc: unify use of timestamp with time zone vs timestamptz For pg_stat_all_tables, last_vacuum, last_autovacuum and co all used the full "timestamp with time zone" type name. For consistency, make the newly added "last_seq_scan" also use the full type name instead of "timestamptz". Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/DM4PR84MB17348EA11FA90A9BE896AF89EE489%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
2023-06-05 07:34:27 +02:00
<structfield>last_idx_scan</structfield> <type>timestamp with time zone</type>
pgstat: Track time of the last scan of a relation It can be useful to know when a relation has last been used, e.g., when evaluating whether an index is still required. It was already possible to infer the time of the last usage by tracking, e.g., pg_stat_all_indexes.idx_scan over time. But far from everybody does so. To make it easier to detect the last time a relation has been scanned, track that time in each relation's pgstat entry. To minimize overhead a) the timestamp is updated only when the backend pending stats entry is flushed to shared stats b) the last transaction's stop timestamp is used as the timestamp. Bumps catalog and stats format versions. Author: Dave Page <dpage@pgadmin.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bruce Momjian <bruce@momjian.us> Reviewed-by: Vik Fearing <vik@postgresfriends.org> Discussion: https://postgr.es/m/CA+OCxozrVHNFVEPkweUHMZje+t1tfY816d9MZYc6eZwOOusOaQ@mail.gmail.com
2022-10-14 20:11:34 +02:00
</para>
<para>
The time of the last index scan on this table, based on the
most recent transaction stop time
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_tup_fetch</structfield> <type>bigint</type>
</para>
<para>
Number of live rows fetched by index scans
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_tup_ins</structfield> <type>bigint</type>
</para>
<para>
Count updates that move row to a new page. Add pgstat counter to track row updates that result in the successor version going to a new heap page, leaving behind an original version whose t_ctid points to the new version. The current count is shown by the n_tup_newpage_upd column of each of the pg_stat_*_tables views. The new n_tup_newpage_upd column complements the existing n_tup_hot_upd and n_tup_upd columns. Tables that have high n_tup_newpage_upd values (relative to n_tup_upd) are good candidates for tuning heap fillfactor. Corey Huinker, with small tweaks by me. Author: Corey Huinker <corey.huinker@gmail.com> Reviewed-By: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CADkLM=ded21M9iZ36hHm-vj2rE2d=zcKpUQMds__Xm2pxLfHKA@mail.gmail.com
2023-03-23 19:16:17 +01:00
Total number of rows inserted
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_tup_upd</structfield> <type>bigint</type>
</para>
<para>
Count updates that move row to a new page. Add pgstat counter to track row updates that result in the successor version going to a new heap page, leaving behind an original version whose t_ctid points to the new version. The current count is shown by the n_tup_newpage_upd column of each of the pg_stat_*_tables views. The new n_tup_newpage_upd column complements the existing n_tup_hot_upd and n_tup_upd columns. Tables that have high n_tup_newpage_upd values (relative to n_tup_upd) are good candidates for tuning heap fillfactor. Corey Huinker, with small tweaks by me. Author: Corey Huinker <corey.huinker@gmail.com> Reviewed-By: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CADkLM=ded21M9iZ36hHm-vj2rE2d=zcKpUQMds__Xm2pxLfHKA@mail.gmail.com
2023-03-23 19:16:17 +01:00
Total number of rows updated. (This includes row updates
counted in <structfield>n_tup_hot_upd</structfield> and
<structfield>n_tup_newpage_upd</structfield>, and remaining
non-<acronym>HOT</acronym> updates.)
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_tup_del</structfield> <type>bigint</type>
</para>
<para>
Count updates that move row to a new page. Add pgstat counter to track row updates that result in the successor version going to a new heap page, leaving behind an original version whose t_ctid points to the new version. The current count is shown by the n_tup_newpage_upd column of each of the pg_stat_*_tables views. The new n_tup_newpage_upd column complements the existing n_tup_hot_upd and n_tup_upd columns. Tables that have high n_tup_newpage_upd values (relative to n_tup_upd) are good candidates for tuning heap fillfactor. Corey Huinker, with small tweaks by me. Author: Corey Huinker <corey.huinker@gmail.com> Reviewed-By: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CADkLM=ded21M9iZ36hHm-vj2rE2d=zcKpUQMds__Xm2pxLfHKA@mail.gmail.com
2023-03-23 19:16:17 +01:00
Total number of rows deleted
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_tup_hot_upd</structfield> <type>bigint</type>
</para>
<para>
Count updates that move row to a new page. Add pgstat counter to track row updates that result in the successor version going to a new heap page, leaving behind an original version whose t_ctid points to the new version. The current count is shown by the n_tup_newpage_upd column of each of the pg_stat_*_tables views. The new n_tup_newpage_upd column complements the existing n_tup_hot_upd and n_tup_upd columns. Tables that have high n_tup_newpage_upd values (relative to n_tup_upd) are good candidates for tuning heap fillfactor. Corey Huinker, with small tweaks by me. Author: Corey Huinker <corey.huinker@gmail.com> Reviewed-By: Peter Geoghegan <pg@bowt.ie> Reviewed-By: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CADkLM=ded21M9iZ36hHm-vj2rE2d=zcKpUQMds__Xm2pxLfHKA@mail.gmail.com
2023-03-23 19:16:17 +01:00
Number of rows <link linkend="storage-hot">HOT updated</link>.
These are updates where no successor versions are required in
indexes.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_tup_newpage_upd</structfield> <type>bigint</type>
</para>
<para>
Number of rows updated where the successor version goes onto a
<emphasis>new</emphasis> heap page, leaving behind an original
version with a
<link linkend="storage-tuple-layout"><structfield>t_ctid</structfield>
field</link> that points to a different heap page. These are
always non-<acronym>HOT</acronym> updates.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_live_tup</structfield> <type>bigint</type>
</para>
<para>
Estimated number of live rows
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_dead_tup</structfield> <type>bigint</type>
</para>
<para>
Estimated number of dead rows
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_mod_since_analyze</structfield> <type>bigint</type>
</para>
<para>
Estimated number of rows modified since this table was last analyzed
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>n_ins_since_vacuum</structfield> <type>bigint</type>
</para>
<para>
Estimated number of rows inserted since this table was last vacuumed
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_vacuum</structfield> <type>timestamp with time zone</type>
</para>
<para>
Last time at which this table was manually vacuumed
(not counting <command>VACUUM FULL</command>)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_autovacuum</structfield> <type>timestamp with time zone</type>
</para>
<para>
Last time at which this table was vacuumed by the autovacuum
daemon
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_analyze</structfield> <type>timestamp with time zone</type>
</para>
<para>
Last time at which this table was manually analyzed
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>last_autoanalyze</structfield> <type>timestamp with time zone</type>
</para>
<para>
Last time at which this table was analyzed by the autovacuum
daemon
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>vacuum_count</structfield> <type>bigint</type>
</para>
<para>
Number of times this table has been manually vacuumed
(not counting <command>VACUUM FULL</command>)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>autovacuum_count</structfield> <type>bigint</type>
</para>
<para>
Number of times this table has been vacuumed by the autovacuum
daemon
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>analyze_count</structfield> <type>bigint</type>
</para>
<para>
Number of times this table has been manually analyzed
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>autoanalyze_count</structfield> <type>bigint</type>
</para>
<para>
Number of times this table has been analyzed by the autovacuum
daemon
</para></entry>
</row>
</tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-all-indexes-view">
<title><structname>pg_stat_all_indexes</structname></title>
<indexterm>
<primary>pg_stat_all_indexes</primary>
</indexterm>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_all_indexes</structname> view will contain
one row for each index in the current database,
showing statistics about accesses to that specific index. The
<structname>pg_stat_user_indexes</structname> and
<structname>pg_stat_sys_indexes</structname> views
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
contain the same information,
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
but filtered to only show user and system indexes respectively.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</para>
<table id="pg-stat-all-indexes-view" xreflabel="pg_stat_all_indexes">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_stat_all_indexes</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of the table for this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexrelid</structfield> <type>oid</type>
</para>
<para>
OID of this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
</para>
<para>
Name of the schema this index is in
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relname</structfield> <type>name</type>
</para>
<para>
Name of the table for this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexrelname</structfield> <type>name</type>
</para>
<para>
Name of this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_scan</structfield> <type>bigint</type>
</para>
<para>
Number of index scans initiated on this index
</para></entry>
</row>
pgstat: Track time of the last scan of a relation It can be useful to know when a relation has last been used, e.g., when evaluating whether an index is still required. It was already possible to infer the time of the last usage by tracking, e.g., pg_stat_all_indexes.idx_scan over time. But far from everybody does so. To make it easier to detect the last time a relation has been scanned, track that time in each relation's pgstat entry. To minimize overhead a) the timestamp is updated only when the backend pending stats entry is flushed to shared stats b) the last transaction's stop timestamp is used as the timestamp. Bumps catalog and stats format versions. Author: Dave Page <dpage@pgadmin.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bruce Momjian <bruce@momjian.us> Reviewed-by: Vik Fearing <vik@postgresfriends.org> Discussion: https://postgr.es/m/CA+OCxozrVHNFVEPkweUHMZje+t1tfY816d9MZYc6eZwOOusOaQ@mail.gmail.com
2022-10-14 20:11:34 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Doc: unify use of timestamp with time zone vs timestamptz For pg_stat_all_tables, last_vacuum, last_autovacuum and co all used the full "timestamp with time zone" type name. For consistency, make the newly added "last_seq_scan" also use the full type name instead of "timestamptz". Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/DM4PR84MB17348EA11FA90A9BE896AF89EE489%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
2023-06-05 07:34:27 +02:00
<structfield>last_idx_scan</structfield> <type>timestamp with time zone</type>
pgstat: Track time of the last scan of a relation It can be useful to know when a relation has last been used, e.g., when evaluating whether an index is still required. It was already possible to infer the time of the last usage by tracking, e.g., pg_stat_all_indexes.idx_scan over time. But far from everybody does so. To make it easier to detect the last time a relation has been scanned, track that time in each relation's pgstat entry. To minimize overhead a) the timestamp is updated only when the backend pending stats entry is flushed to shared stats b) the last transaction's stop timestamp is used as the timestamp. Bumps catalog and stats format versions. Author: Dave Page <dpage@pgadmin.org> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Bruce Momjian <bruce@momjian.us> Reviewed-by: Vik Fearing <vik@postgresfriends.org> Discussion: https://postgr.es/m/CA+OCxozrVHNFVEPkweUHMZje+t1tfY816d9MZYc6eZwOOusOaQ@mail.gmail.com
2022-10-14 20:11:34 +02:00
</para>
<para>
The time of the last scan on this index, based on the
most recent transaction stop time
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_tup_read</structfield> <type>bigint</type>
</para>
<para>
Number of index entries returned by scans on this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_tup_fetch</structfield> <type>bigint</type>
</para>
<para>
Number of live table rows fetched by simple index scans using this
index
</para></entry>
</row>
</tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</tgroup>
</table>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Indexes can be used by simple index scans, <quote>bitmap</quote> index scans,
docs: mention the optimizer can increase the index usage count Report by Marko Tiikkaja
2015-03-20 03:38:12 +01:00
and the optimizer. In a bitmap scan
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
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
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structname>pg_stat_all_indexes</structname>.<structfield>idx_tup_read</structfield>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
count(s) for the index(es) it uses, and it increments the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structname>pg_stat_all_tables</structname>.<structfield>idx_tup_fetch</structfield>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
count for the table, but it does not affect
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structname>pg_stat_all_indexes</structname>.<structfield>idx_tup_fetch</structfield>.
docs: mention the optimizer can increase the index usage count Report by Marko Tiikkaja
2015-03-20 03:38:12 +01:00
The optimizer also accesses indexes to check for supplied constants
whose values are outside the recorded range of the optimizer statistics
because the optimizer statistics might be stale.
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
</para>
<note>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
The <structfield>idx_tup_read</structfield> and <structfield>idx_tup_fetch</structfield> counts
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
can be different even without any use of bitmap scans,
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
because <structfield>idx_tup_read</structfield> counts
index entries retrieved from the index while <structfield>idx_tup_fetch</structfield>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
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, or if any
heap fetches are avoided by means of an index-only scan.
</para>
</note>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-statio-all-tables-view">
<title><structname>pg_statio_all_tables</structname></title>
<indexterm>
<primary>pg_statio_all_tables</primary>
</indexterm>
<para>
The <structname>pg_statio_all_tables</structname> view will contain
one row for each table in the current database (including TOAST
tables), showing statistics about I/O on that specific table. The
<structname>pg_statio_user_tables</structname> and
<structname>pg_statio_sys_tables</structname> views
contain the same information,
but filtered to only show user and system tables respectively.
</para>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<table id="pg-statio-all-tables-view" xreflabel="pg_statio_all_tables">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_statio_all_tables</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of a table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
</para>
<para>
Name of the schema that this table is in
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relname</structfield> <type>name</type>
</para>
<para>
Name of this table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>heap_blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read from this table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>heap_blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of buffer hits in this table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read from all indexes on this table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of buffer hits in all indexes on this table
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>toast_blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read from this table's TOAST table (if any)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>toast_blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of buffer hits in this table's TOAST table (if any)
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tidx_blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read from this table's TOAST table indexes (if any)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tidx_blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of buffer hits in this table's TOAST table indexes (if any)
</para></entry>
</row>
</tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-statio-all-indexes-view">
<title><structname>pg_statio_all_indexes</structname></title>
<indexterm>
<primary>pg_statio_all_indexes</primary>
</indexterm>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_statio_all_indexes</structname> view will contain
one row for each index in the current database,
showing statistics about I/O on that specific index. The
<structname>pg_statio_user_indexes</structname> and
<structname>pg_statio_sys_indexes</structname> views
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
contain the same information,
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
but filtered to only show user and system indexes respectively.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</para>
<table id="pg-statio-all-indexes-view" xreflabel="pg_statio_all_indexes">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_statio_all_indexes</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of the table for this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexrelid</structfield> <type>oid</type>
</para>
<para>
OID of this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
</para>
<para>
Name of the schema this index is in
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relname</structfield> <type>name</type>
</para>
<para>
Name of the table for this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexrelname</structfield> <type>name</type>
</para>
<para>
Name of this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read from this index
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>idx_blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of buffer hits in this index
</para></entry>
</row>
</tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-statio-all-sequences-view">
<title><structname>pg_statio_all_sequences</structname></title>
<indexterm>
<primary>pg_statio_all_sequences</primary>
</indexterm>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_statio_all_sequences</structname> view will contain
one row for each sequence in the current database,
showing statistics about I/O on that specific sequence.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</para>
<table id="pg-statio-all-sequences-view" xreflabel="pg_statio_all_sequences">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_statio_all_sequences</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of a sequence
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
</para>
<para>
Name of the schema this sequence is in
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relname</structfield> <type>name</type>
</para>
<para>
Name of this sequence
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read from this sequence
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of buffer hits in this sequence
</para></entry>
</row>
</tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-user-functions-view">
<title><structname>pg_stat_user_functions</structname></title>
<indexterm>
<primary>pg_stat_user_functions</primary>
</indexterm>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<para>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
The <structname>pg_stat_user_functions</structname> view will contain
one row for each tracked function, showing statistics about executions of
that function. The <xref linkend="guc-track-functions"/> parameter
controls exactly which functions are tracked.
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</para>
<table id="pg-stat-user-functions-view" xreflabel="pg_stat_user_functions">
Documentation spell and markup checking
2012-06-07 23:06:20 +02:00
<title><structname>pg_stat_user_functions</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>funcid</structfield> <type>oid</type>
</para>
<para>
OID of a function
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>schemaname</structfield> <type>name</type>
</para>
<para>
Name of the schema this function is in
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>funcname</structfield> <type>name</type>
</para>
<para>
Name of this function
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>calls</structfield> <type>bigint</type>
</para>
<para>
Number of times this function has been called
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>total_time</structfield> <type>double precision</type>
</para>
<para>
Total time spent in this function and all other functions
called by it, in milliseconds
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>self_time</structfield> <type>double precision</type>
</para>
<para>
Total time spent in this function itself, not including
other functions called by it, in milliseconds
</para></entry>
</row>
</tbody>
Make each pg_stat_ view into it's own table in the documentation This makes it easier to match a column name with the description of it, and makes it possible to add more detailed documentation in the future. This patch does not add that extra documentation at this point, only the structure required for it. Modeled on the changes already done to pg_stat_activity.
2012-02-25 15:20:49 +01:00
</tgroup>
</table>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
</sect2>
<sect2 id="monitoring-pg-stat-slru-view">
<title><structname>pg_stat_slru</structname></title>
Rename SLRU structures and associated LWLocks. Originally, the names assigned to SLRUs had no purpose other than being shmem lookup keys, so not a lot of thought went into them. As of v13, though, we're exposing them in the pg_stat_slru view and the pg_stat_reset_slru function, so it seems advisable to take a bit more care. Rename them to names based on the associated on-disk storage directories (which fortunately we *did* think about, to some extent; since those are also visible to DBAs, consistency seems like a good thing). Also rename the associated LWLocks, since those names are likewise user-exposed now as wait event names. For the most part I only touched symbols used in the respective modules' SimpleLruInit() calls, not the names of other related objects. This renaming could have been taken further, and maybe someday we will do so. But for now it seems undesirable to change the names of any globally visible functions or structs, so some inconsistency is unavoidable. (But I *did* terminate "oldserxid" with prejudice, as I found that name both unreadable and not descriptive of the SLRU's contents.) Table 27.12 needs re-alphabetization now, but I'll leave that till after the other LWLock renamings I have in mind. Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
<indexterm>
<primary>SLRU</primary>
</indexterm>
doc: Update the layout of "Viewing Statistics" section. This commit updates the "Viewing Statistics" section more like the existing catalogs chapter. - Change its layout so that an introductory paragrap is put above the table for each statistics view. Previously the explanations were below the tables. - Separate each view to different section and add index terms for them. Author: Fujii Masao Reviewed-by: Tom Lane Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com
2020-05-29 10:14:33 +02:00
<indexterm>
<primary>pg_stat_slru</primary>
</indexterm>
Collect statistics about SLRU caches There's a number of SLRU caches used to access important data like clog, commit timestamps, multixact, asynchronous notifications, etc. Until now we had no easy way to monitor these shared caches, compute hit ratios, number of reads/writes etc. This commit extends the statistics collector to track this information for a predefined list of SLRUs, and also introduces a new system view pg_stat_slru displaying the data. The list of built-in SLRUs is fixed, but additional SLRUs may be defined in extensions. Unfortunately, there's no suitable registry of SLRUs, so this patch simply defines a fixed list of SLRUs with entries for the built-in ones and one entry for all additional SLRUs. Extensions adding their own SLRU are fairly rare, so this seems acceptable. This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes are still fixed (hard-coded in the code) and it's not entirely clear which of the SLRUs might need a GUC to tune size. In a way, allowing us to determine that is one of the goals of this patch. Bump catversion as the patch introduces new functions and system view. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development
2020-04-02 02:11:38 +02:00
<para>
Rename SLRU structures and associated LWLocks. Originally, the names assigned to SLRUs had no purpose other than being shmem lookup keys, so not a lot of thought went into them. As of v13, though, we're exposing them in the pg_stat_slru view and the pg_stat_reset_slru function, so it seems advisable to take a bit more care. Rename them to names based on the associated on-disk storage directories (which fortunately we *did* think about, to some extent; since those are also visible to DBAs, consistency seems like a good thing). Also rename the associated LWLocks, since those names are likewise user-exposed now as wait event names. For the most part I only touched symbols used in the respective modules' SimpleLruInit() calls, not the names of other related objects. This renaming could have been taken further, and maybe someday we will do so. But for now it seems undesirable to change the names of any globally visible functions or structs, so some inconsistency is unavoidable. (But I *did* terminate "oldserxid" with prejudice, as I found that name both unreadable and not descriptive of the SLRU's contents.) Table 27.12 needs re-alphabetization now, but I'll leave that till after the other LWLock renamings I have in mind. Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
<productname>PostgreSQL</productname> accesses certain on-disk information
Improve performance of subsystems on top of SLRU More precisely, what we do here is make the SLRU cache sizes configurable with new GUCs, so that sites with high concurrency and big ranges of transactions in flight (resp. multixacts/subtransactions) can benefit from bigger caches. In order for this to work with good performance, two additional changes are made: 1. the cache is divided in "banks" (to borrow terminology from CPU caches), and algorithms such as eviction buffer search only affect one specific bank. This forestalls the problem that linear searching for a specific buffer across the whole cache takes too long: we only have to search the specific bank, whose size is small. This work is authored by Andrey Borodin. 2. Change the locking regime for the SLRU banks, so that each bank uses a separate LWLock. This allows for increased scalability. This work is authored by Dilip Kumar. (A part of this was previously committed as d172b717c6f4.) Special care is taken so that the algorithms that can potentially traverse more than one bank release one bank's lock before acquiring the next. This should happen rarely, but particularly clog.c's group commit feature needed code adjustment to cope with this. I (Álvaro) also added lots of comments to make sure the design is sound. The new GUCs match the names introduced by bcdfa5f2e2f2 in the pg_stat_slru view. The default values for these parameters are similar to the previous sizes of each SLRU. commit_ts, clog and subtrans accept value 0, which means to adjust by dividing shared_buffers by 512 (so 2MB for every 1GB of shared_buffers), with a cap of 8MB. (A new slru.c function SimpleLruAutotuneBuffers() was added to support this.) The cap was previously 1MB for clog, so for sites with more than 512MB of shared memory the total memory used increases, which is likely a good tradeoff. However, other SLRUs (notably multixact ones) retain smaller sizes and don't support a configured value of 0. These values based on shared_buffers may need to be revisited, but that's an easy change. There was some resistance to adding these new GUCs: it would be better to adjust to memory pressure automatically somehow, for example by stealing memory from shared_buffers (where the caches can grow and shrink naturally). However, doing that seems to be a much larger project and one which has made virtually no progress in several years, and because this is such a pain point for so many users, here we take the pragmatic approach. Author: Andrey Borodin <x4mmm@yandex-team.ru> Author: Dilip Kumar <dilipbalaut@gmail.com> Reviewed-by: Amul Sul, Gilles Darold, Anastasia Lubennikova, Ivan Lazarev, Robert Haas, Thomas Munro, Tomas Vondra, Yura Sokolov, Васильев Дмитрий (Dmitry Vasiliev). Discussion: https://postgr.es/m/2BEC2B3F-9B61-4C1D-9FB5-5FAB0F05EF86@yandex-team.ru Discussion: https://postgr.es/m/CAFiTN-vzDvNz=ExGXz6gdyjtzGixKSqs0mKHMmaQ8sOSEFZ33A@mail.gmail.com
2024-02-28 17:05:31 +01:00
via <literal>SLRU</literal> (<firstterm>simple least-recently-used</firstterm>)
caches.
Collect statistics about SLRU caches There's a number of SLRU caches used to access important data like clog, commit timestamps, multixact, asynchronous notifications, etc. Until now we had no easy way to monitor these shared caches, compute hit ratios, number of reads/writes etc. This commit extends the statistics collector to track this information for a predefined list of SLRUs, and also introduces a new system view pg_stat_slru displaying the data. The list of built-in SLRUs is fixed, but additional SLRUs may be defined in extensions. Unfortunately, there's no suitable registry of SLRUs, so this patch simply defines a fixed list of SLRUs with entries for the built-in ones and one entry for all additional SLRUs. Extensions adding their own SLRU are fairly rare, so this seems acceptable. This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes are still fixed (hard-coded in the code) and it's not entirely clear which of the SLRUs might need a GUC to tune size. In a way, allowing us to determine that is one of the goals of this patch. Bump catversion as the patch introduces new functions and system view. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development
2020-04-02 02:11:38 +02:00
The <structname>pg_stat_slru</structname> view will contain
one row for each tracked SLRU cache, showing statistics about access
to cached pages.
</para>
Improve performance of subsystems on top of SLRU More precisely, what we do here is make the SLRU cache sizes configurable with new GUCs, so that sites with high concurrency and big ranges of transactions in flight (resp. multixacts/subtransactions) can benefit from bigger caches. In order for this to work with good performance, two additional changes are made: 1. the cache is divided in "banks" (to borrow terminology from CPU caches), and algorithms such as eviction buffer search only affect one specific bank. This forestalls the problem that linear searching for a specific buffer across the whole cache takes too long: we only have to search the specific bank, whose size is small. This work is authored by Andrey Borodin. 2. Change the locking regime for the SLRU banks, so that each bank uses a separate LWLock. This allows for increased scalability. This work is authored by Dilip Kumar. (A part of this was previously committed as d172b717c6f4.) Special care is taken so that the algorithms that can potentially traverse more than one bank release one bank's lock before acquiring the next. This should happen rarely, but particularly clog.c's group commit feature needed code adjustment to cope with this. I (Álvaro) also added lots of comments to make sure the design is sound. The new GUCs match the names introduced by bcdfa5f2e2f2 in the pg_stat_slru view. The default values for these parameters are similar to the previous sizes of each SLRU. commit_ts, clog and subtrans accept value 0, which means to adjust by dividing shared_buffers by 512 (so 2MB for every 1GB of shared_buffers), with a cap of 8MB. (A new slru.c function SimpleLruAutotuneBuffers() was added to support this.) The cap was previously 1MB for clog, so for sites with more than 512MB of shared memory the total memory used increases, which is likely a good tradeoff. However, other SLRUs (notably multixact ones) retain smaller sizes and don't support a configured value of 0. These values based on shared_buffers may need to be revisited, but that's an easy change. There was some resistance to adding these new GUCs: it would be better to adjust to memory pressure automatically somehow, for example by stealing memory from shared_buffers (where the caches can grow and shrink naturally). However, doing that seems to be a much larger project and one which has made virtually no progress in several years, and because this is such a pain point for so many users, here we take the pragmatic approach. Author: Andrey Borodin <x4mmm@yandex-team.ru> Author: Dilip Kumar <dilipbalaut@gmail.com> Reviewed-by: Amul Sul, Gilles Darold, Anastasia Lubennikova, Ivan Lazarev, Robert Haas, Thomas Munro, Tomas Vondra, Yura Sokolov, Васильев Дмитрий (Dmitry Vasiliev). Discussion: https://postgr.es/m/2BEC2B3F-9B61-4C1D-9FB5-5FAB0F05EF86@yandex-team.ru Discussion: https://postgr.es/m/CAFiTN-vzDvNz=ExGXz6gdyjtzGixKSqs0mKHMmaQ8sOSEFZ33A@mail.gmail.com
2024-02-28 17:05:31 +01:00
<para>
For each <literal>SLRU</literal> cache that's part of the core server,
there is a configuration parameter that controls its size, with the suffix
<literal>_buffers</literal> appended.
</para>
Collect statistics about SLRU caches There's a number of SLRU caches used to access important data like clog, commit timestamps, multixact, asynchronous notifications, etc. Until now we had no easy way to monitor these shared caches, compute hit ratios, number of reads/writes etc. This commit extends the statistics collector to track this information for a predefined list of SLRUs, and also introduces a new system view pg_stat_slru displaying the data. The list of built-in SLRUs is fixed, but additional SLRUs may be defined in extensions. Unfortunately, there's no suitable registry of SLRUs, so this patch simply defines a fixed list of SLRUs with entries for the built-in ones and one entry for all additional SLRUs. Extensions adding their own SLRU are fairly rare, so this seems acceptable. This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes are still fixed (hard-coded in the code) and it's not entirely clear which of the SLRUs might need a GUC to tune size. In a way, allowing us to determine that is one of the goals of this patch. Bump catversion as the patch introduces new functions and system view. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development
2020-04-02 02:11:38 +02:00
<table id="pg-stat-slru-view" xreflabel="pg_stat_slru">
<title><structname>pg_stat_slru</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Collect statistics about SLRU caches There's a number of SLRU caches used to access important data like clog, commit timestamps, multixact, asynchronous notifications, etc. Until now we had no easy way to monitor these shared caches, compute hit ratios, number of reads/writes etc. This commit extends the statistics collector to track this information for a predefined list of SLRUs, and also introduces a new system view pg_stat_slru displaying the data. The list of built-in SLRUs is fixed, but additional SLRUs may be defined in extensions. Unfortunately, there's no suitable registry of SLRUs, so this patch simply defines a fixed list of SLRUs with entries for the built-in ones and one entry for all additional SLRUs. Extensions adding their own SLRU are fairly rare, so this seems acceptable. This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes are still fixed (hard-coded in the code) and it's not entirely clear which of the SLRUs might need a GUC to tune size. In a way, allowing us to determine that is one of the goals of this patch. Bump catversion as the patch introduces new functions and system view. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development
2020-04-02 02:11:38 +02:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Collect statistics about SLRU caches There's a number of SLRU caches used to access important data like clog, commit timestamps, multixact, asynchronous notifications, etc. Until now we had no easy way to monitor these shared caches, compute hit ratios, number of reads/writes etc. This commit extends the statistics collector to track this information for a predefined list of SLRUs, and also introduces a new system view pg_stat_slru displaying the data. The list of built-in SLRUs is fixed, but additional SLRUs may be defined in extensions. Unfortunately, there's no suitable registry of SLRUs, so this patch simply defines a fixed list of SLRUs with entries for the built-in ones and one entry for all additional SLRUs. Extensions adding their own SLRU are fairly rare, so this seems acceptable. This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes are still fixed (hard-coded in the code) and it's not entirely clear which of the SLRUs might need a GUC to tune size. In a way, allowing us to determine that is one of the goals of this patch. Bump catversion as the patch introduces new functions and system view. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development
2020-04-02 02:11:38 +02:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>name</structfield> <type>text</type>
</para>
<para>
doc: Fix format, incorrect structure names and markup inconsistencies Author: Alexander Lakhin Discussion: https://postgr.es/m/a2345841-10a5-4eef-257c-02302347cf39@gmail.com Backpatch-through: 13
2020-08-22 15:26:10 +02:00
Name of the SLRU
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_zeroed</structfield> <type>bigint</type>
</para>
<para>
Number of blocks zeroed during initializations
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_hit</structfield> <type>bigint</type>
</para>
<para>
Number of times disk blocks were found already in the SLRU,
so that a read was not necessary (this only includes hits in the
SLRU, not the operating system's file system cache)
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_read</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks read for this SLRU
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_written</structfield> <type>bigint</type>
</para>
<para>
Number of disk blocks written for this SLRU
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blks_exists</structfield> <type>bigint</type>
</para>
<para>
Number of blocks checked for existence for this SLRU
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>flushes</structfield> <type>bigint</type>
</para>
<para>
Number of flushes of dirty data for this SLRU
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>truncates</structfield> <type>bigint</type>
</para>
<para>
Number of truncates for this SLRU
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>stats_reset</structfield> <type>timestamp with time zone</type>
</para>
<para>
Time at which these statistics were last reset
</para></entry>
</row>
</tbody>
Collect statistics about SLRU caches There's a number of SLRU caches used to access important data like clog, commit timestamps, multixact, asynchronous notifications, etc. Until now we had no easy way to monitor these shared caches, compute hit ratios, number of reads/writes etc. This commit extends the statistics collector to track this information for a predefined list of SLRUs, and also introduces a new system view pg_stat_slru displaying the data. The list of built-in SLRUs is fixed, but additional SLRUs may be defined in extensions. Unfortunately, there's no suitable registry of SLRUs, so this patch simply defines a fixed list of SLRUs with entries for the built-in ones and one entry for all additional SLRUs. Extensions adding their own SLRU are fairly rare, so this seems acceptable. This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes are still fixed (hard-coded in the code) and it's not entirely clear which of the SLRUs might need a GUC to tune size. In a way, allowing us to determine that is one of the goals of this patch. Bump catversion as the patch introduces new functions and system view. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development
2020-04-02 02:11:38 +02:00
</tgroup>
</table>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
</sect2>
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
<sect2 id="monitoring-stats-functions">
<title>Statistics Functions</title>
<para>
Other ways of looking at the statistics can be set up by writing
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
queries that use the same underlying statistics access functions used by
the standard views shown above. For details such as the functions' names,
consult the definitions of the standard views. (For example, in
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<application>psql</application> you could issue <literal>\d+ pg_stat_activity</literal>.)
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
The access functions for per-database statistics take a database OID as an
argument to identify which database to report on.
The per-table and per-index functions take a table or index OID.
The functions for per-function statistics take a function OID.
Note that only tables, indexes, and functions in the current database
can be seen with these functions.
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
</para>
<para>
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
Additional functions related to the cumulative statistics system are listed
in <xref linkend="monitoring-stats-funcs-table"/>.
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
</para>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<table id="monitoring-stats-funcs-table">
<title>Additional Statistics Functions</title>
<tgroup cols="1">
<thead>
<row>
<entry role="func_table_entry"><para role="func_signature">
Function
</para>
<para>
Description
</para></entry>
</row>
</thead>
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<tbody>
<row>
Make the pg_stat_activity view call a SRF (pg_stat_get_activity()) instead of calling a bunch of individual functions. This function can also be called directly, taking a PID as an argument, to return only the data for a single PID.
2008-05-07 16:41:56 +02:00
<!-- See also the entry for this in func.sgml -->
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<entry role="func_table_entry"><para role="func_signature">
<function>pg_backend_pid</function> ()
<returnvalue>integer</returnvalue>
</para>
<para>
Returns the process ID of the server process attached to the current
session.
</para></entry>
</row>
Rename backend_pid to pg_backend_pid, move docs to monitoring section.
2002-08-04 21:51:30 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_activity</primary>
</indexterm>
<function>pg_stat_get_activity</function> ( <type>integer</type> )
<returnvalue>setof record</returnvalue>
</para>
<para>
Returns a record of information about the backend with the specified
process ID, or one record for each active backend in the system
if <literal>NULL</literal> is specified. The fields returned are a
subset of those in the <structname>pg_stat_activity</structname> view.
</para></entry>
</row>
Make the pg_stat_activity view call a SRF (pg_stat_get_activity()) instead of calling a bunch of individual functions. This function can also be called directly, taking a PID as an argument, to return only the data for a single PID.
2008-05-07 16:41:56 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_snapshot_timestamp</primary>
</indexterm>
<function>pg_stat_get_snapshot_timestamp</function> ()
<returnvalue>timestamp with time zone</returnvalue>
</para>
<para>
pgstat: store statistics in shared memory. Previously the statistics collector received statistics updates via UDP and shared statistics data by writing them out to temporary files regularly. These files can reach tens of megabytes and are written out up to twice a second. This has repeatedly prevented us from adding additional useful statistics. Now statistics are stored in shared memory. Statistics for variable-numbered objects are stored in a dshash hashtable (backed by dynamic shared memory). Fixed-numbered stats are stored in plain shared memory. The header for pgstat.c contains an overview of the architecture. The stats collector is not needed anymore, remove it. By utilizing the transactional statistics drop infrastructure introduced in a prior commit statistics entries cannot "leak" anymore. Previously leaked statistics were dropped by pgstat_vacuum_stat(), called from [auto-]vacuum. On systems with many small relations pgstat_vacuum_stat() could be quite expensive. Now that replicas drop statistics entries for dropped objects, it is not necessary anymore to reset stats when starting from a cleanly shut down replica. Subsequent commits will perform some further code cleanup, adapt docs and add tests. Bumps PGSTAT_FILE_FORMAT_ID. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-By: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Tomas Vondra <tomas.vondra@2ndquadrant.com> (in a much earlier version) Reviewed-By: Arthur Zakirov <a.zakirov@postgrespro.ru> (in a much earlier version) Reviewed-By: Antonin Houska <ah@cybertec.at> (in a much earlier version) Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de Discussion: https://postgr.es/m/20220308205351.2xcn6k4x5yivcxyd@alap3.anarazel.de Discussion: https://postgr.es/m/20210319235115.y3wz7hpnnrshdyv6@alap3.anarazel.de
2022-04-07 06:29:46 +02:00
Returns the timestamp of the current statistics snapshot, or NULL if
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
no statistics snapshot has been taken. A snapshot is taken the first
time cumulative statistics are accessed in a transaction if
<varname>stats_fetch_consistency</varname> is set to
<literal>snapshot</literal>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</para></entry>
</row>
Add pg_stat_get_snapshot_timestamp() to show statistics snapshot timestamp. Per discussion, this could be useful for purposes such as programmatically detecting a nonresponding stats collector. We already have the timestamp anyway, it's just a matter of providing a SQL-accessible function to fetch it. Matt Kelly, reviewed by Jim Nasby
2015-02-20 03:36:50 +01:00
doc: Add description of some missing monitoring functions This commit adds some documentation about two monitoring functions: - pg_stat_get_xact_blocks_fetched() - pg_stat_get_xact_blocks_hit() The description of these functions has been removed in ddfc2d9, later simplified by 5f2b089, assuming that all the functions whose descriptions were removed are used in system views. Unfortunately, some of them were are not used in any system views, so they lacked documentation. This gap exists in the docs for a long time, so backpatch all the way down. Reported-by: Michael Paquier Author: Bertrand Drouvot Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/ZBeeH5UoNkTPrwHO@paquier.xyz Backpatch-through: 11
2023-03-22 10:31:52 +01:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_xact_blocks_fetched</primary>
</indexterm>
<function>pg_stat_get_xact_blocks_fetched</function> ( <type>oid</type> )
<returnvalue>bigint</returnvalue>
</para>
<para>
doc: Add more details about pg_stat_get_xact_blocks_{fetched,hit} The explanation describing the dependency to system read() calls for these two functions has been removed in ddfc2d9. And after more discussion about d69c404, we have concluded that adding more details makes them easier to understand. While on it, use the term "block read requests" (maybe found in cache) rather than "buffers fetched" and "buffer hits". Per discussion with Melanie Plageman, Kyotaro Horiguchi, Bertrand Drouvot and myself. Discussion: https://postgr.es/m/CAAKRu_ZmdiScT4q83OAbfmR5AH-L5zWya3SXjaxiJvhCob-e2A@mail.gmail.com Backpatch-through: 11
2023-04-05 00:59:43 +02:00
Returns the number of block read requests for table or index, in the
current transaction. This number minus
<function>pg_stat_get_xact_blocks_hit</function> gives the number of
kernel <function>read()</function> calls; the number of actual
physical reads is usually lower due to kernel-level buffering.
doc: Add description of some missing monitoring functions This commit adds some documentation about two monitoring functions: - pg_stat_get_xact_blocks_fetched() - pg_stat_get_xact_blocks_hit() The description of these functions has been removed in ddfc2d9, later simplified by 5f2b089, assuming that all the functions whose descriptions were removed are used in system views. Unfortunately, some of them were are not used in any system views, so they lacked documentation. This gap exists in the docs for a long time, so backpatch all the way down. Reported-by: Michael Paquier Author: Bertrand Drouvot Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/ZBeeH5UoNkTPrwHO@paquier.xyz Backpatch-through: 11
2023-03-22 10:31:52 +01:00
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_xact_blocks_hit</primary>
</indexterm>
<function>pg_stat_get_xact_blocks_hit</function> ( <type>oid</type> )
<returnvalue>bigint</returnvalue>
</para>
<para>
doc: Add more details about pg_stat_get_xact_blocks_{fetched,hit} The explanation describing the dependency to system read() calls for these two functions has been removed in ddfc2d9. And after more discussion about d69c404, we have concluded that adding more details makes them easier to understand. While on it, use the term "block read requests" (maybe found in cache) rather than "buffers fetched" and "buffer hits". Per discussion with Melanie Plageman, Kyotaro Horiguchi, Bertrand Drouvot and myself. Discussion: https://postgr.es/m/CAAKRu_ZmdiScT4q83OAbfmR5AH-L5zWya3SXjaxiJvhCob-e2A@mail.gmail.com Backpatch-through: 11
2023-04-05 00:59:43 +02:00
Returns the number of block read requests for table or index, in the
current transaction, found in cache (not triggering kernel
<function>read()</function> calls).
doc: Add description of some missing monitoring functions This commit adds some documentation about two monitoring functions: - pg_stat_get_xact_blocks_fetched() - pg_stat_get_xact_blocks_hit() The description of these functions has been removed in ddfc2d9, later simplified by 5f2b089, assuming that all the functions whose descriptions were removed are used in system views. Unfortunately, some of them were are not used in any system views, so they lacked documentation. This gap exists in the docs for a long time, so backpatch all the way down. Reported-by: Michael Paquier Author: Bertrand Drouvot Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/ZBeeH5UoNkTPrwHO@paquier.xyz Backpatch-through: 11
2023-03-22 10:31:52 +01:00
</para></entry>
</row>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_clear_snapshot</primary>
</indexterm>
<function>pg_stat_clear_snapshot</function> ()
<returnvalue>void</returnvalue>
</para>
<para>
pgstat: Update docs to match the shared memory stats reality. This includes removing documentation for stats_temp_directory, adding documentation for stats_fetch_consistency, rephrasing references to the stats collector and documenting that starting a cleanly shut down standby will not remove stats anymore. The latter point might require further wordsmithing, it wasn't easy to adjust some of the existing content. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Lukas Fittl <lukas@fittl.com> Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de
2022-04-08 06:35:35 +02:00
Discards the current statistics snapshot or cached information.
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</para></entry>
</row>
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_reset</primary>
</indexterm>
<function>pg_stat_reset</function> ()
<returnvalue>void</returnvalue>
</para>
<para>
Resets all statistics counters for the current database to zero.
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
</para></entry>
</row>
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_reset_shared</primary>
</indexterm>
Add ability to reset all shared stats types in pg_stat_reset_shared() Currently, pg_stat_reset_shared() can use an argument to specify the target of statistics to reset, doing nothing for NULL as it is strict. This patch adds to pg_stat_reset_shared() the possibility to reset all the stats types already handled in this function rather than do nothing if the argument value given is NULL or if nothing is specified (proisstrict is switched to false). Like previously, SLRUs are not included in what gets reset. The idea to use NULL or no argument to control if all the shared stats already covered by this function should be reset has been proposed by Andres Freund. Bump catalog version. Author: Atsushi Torikoshi Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Bharath Rupireddy, Matthias van de Meent Discussion: https://postgr.es/m/4291a55137ddda77cf7cc5f46e846daf@oss.nttdata.com
2023-11-12 08:43:12 +01:00
<function>pg_stat_reset_shared</function> ( [ <parameter>target</parameter> <type>text</type> <literal>DEFAULT</literal> <literal>NULL</literal> ] )
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<returnvalue>void</returnvalue>
</para>
<para>
Resets some cluster-wide statistics counters to zero, depending on the
doc: Improve description of targets for pg_stat_reset_shared() This commit changes the documentation so as the supported targets are documented with itemized list, making it easier to understand the view a given target affects. Author: Atsushi Torikoshi Discussion: https://postgr.es/m/e3c25d72e81378e7b64f3c52e0306fc9@oss.nttdata.com
2023-11-15 01:41:10 +01:00
argument. <parameter>target</parameter> can be:
<itemizedlist>
<listitem>
<para>
<literal>archiver</literal>: Reset all the counters shown in the
<structname>pg_stat_archiver</structname> view.
</para>
</listitem>
<listitem>
<para>
<literal>bgwriter</literal>: Reset all the counters shown in the
<structname>pg_stat_bgwriter</structname> view.
</para>
</listitem>
<listitem>
<para>
<literal>checkpointer</literal>: Reset all the counters shown in the
<structname>pg_stat_checkpointer</structname> view.
</para>
</listitem>
<listitem>
<para>
<literal>io</literal>: Reset all the counters shown in the
<structname>pg_stat_io</structname> view.
</para>
</listitem>
<listitem>
<para>
<literal>recovery_prefetch</literal>: Reset all the counters shown in
the <structname>pg_stat_recovery_prefetch</structname> view.
</para>
</listitem>
Add target "slru" to pg_stat_reset_shared() Currently, pg_stat_reset_shared() cannot reset the counters in the view pg_stat_slru even if it is a type of shared stats. This patch adds support for a new value in pg_stat_reset_shared(), called "slru", able to do that. Note that pg_stat_reset_shared(NULL) also resets SLRU counters. There may be a point in removing pg_stat_reset_slru() that was introduced in 28cac71bd368 (v13~) as the new option overlaps with this function, but we would lose the ability to reset individual SLRU counters. This is left for future reconsideration. Author: Atsushi Torikoshi Discussion: https://postgr.es/m/e3c25d72e81378e7b64f3c52e0306fc9@oss.nttdata.com
2023-11-16 07:41:34 +01:00
<listitem>
<para>
<literal>slru</literal>: Reset all the counters shown in the
<structname>pg_stat_slru</structname> view.
</para>
</listitem>
doc: Improve description of targets for pg_stat_reset_shared() This commit changes the documentation so as the supported targets are documented with itemized list, making it easier to understand the view a given target affects. Author: Atsushi Torikoshi Discussion: https://postgr.es/m/e3c25d72e81378e7b64f3c52e0306fc9@oss.nttdata.com
2023-11-15 01:41:10 +01:00
<listitem>
<para>
<literal>wal</literal>: Reset all the counters shown in the
<structname>pg_stat_wal</structname> view.
</para>
</listitem>
<listitem>
<para>
<literal>NULL</literal> or not specified: All the counters from the
views listed above are reset.
</para>
</listitem>
</itemizedlist>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
</para></entry>
</row>
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_reset_single_table_counters</primary>
</indexterm>
<function>pg_stat_reset_single_table_counters</function> ( <type>oid</type> )
<returnvalue>void</returnvalue>
</para>
<para>
Resets statistics for a single table or index in the current database
Enhance pg_stat_reset_single_table_counters function. This commit allows pg_stat_reset_single_table_counters() to reset statistics for a single relation shared across all databases in the cluster to zero. Bump catalog version. Author: B Sadhu Prasad Patro Reviewed-by: Mahendra Singh Thalor, Himanshu Upadhyaya, Dilip Kumar, Fujii Masao Discussion: https://postgr.es/m/CAFF0-CGy7EHeF=AqqkGMF85cySPQBgDcvNk73G2O0vL94O5U5A@mail.gmail.com
2021-09-02 07:01:06 +02:00
or shared across all databases in the cluster to zero.
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
</para></entry>
</row>
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_reset_single_function_counters</primary>
</indexterm>
<function>pg_stat_reset_single_function_counters</function> ( <type>oid</type> )
<returnvalue>void</returnvalue>
</para>
<para>
Resets statistics for a single function in the current database to
zero.
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
</para></entry>
</row>
Collect statistics about SLRU caches There's a number of SLRU caches used to access important data like clog, commit timestamps, multixact, asynchronous notifications, etc. Until now we had no easy way to monitor these shared caches, compute hit ratios, number of reads/writes etc. This commit extends the statistics collector to track this information for a predefined list of SLRUs, and also introduces a new system view pg_stat_slru displaying the data. The list of built-in SLRUs is fixed, but additional SLRUs may be defined in extensions. Unfortunately, there's no suitable registry of SLRUs, so this patch simply defines a fixed list of SLRUs with entries for the built-in ones and one entry for all additional SLRUs. Extensions adding their own SLRU are fairly rare, so this seems acceptable. This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes are still fixed (hard-coded in the code) and it's not entirely clear which of the SLRUs might need a GUC to tune size. In a way, allowing us to determine that is one of the goals of this patch. Bump catversion as the patch introduces new functions and system view. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development
2020-04-02 02:11:38 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_reset_slru</primary>
</indexterm>
Add support for pg_stat_reset_slru without argument pg_stat_reset_slru currently requires an input argument, either: - NULL to reset the SLRU counters of everything. - A specific value to reset a single SLRU cache. This commit adds support for a new pattern: pg_stat_reset_slru without any argument works the same way as pg_stat_reset_slru(NULL), relying on a DEFAULT in the function definition to handle this case. This makes the function more consistent with 23c8c0c8f472. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Atsushi Torikoshi Discussion: https://postgr.es/m/CALj2ACW1VizYg01EeH_cA-7qA+4NzWVAoZ5Lw9_XYO1RRHAZbA@mail.gmail.com
2023-11-14 01:50:52 +01:00
<function>pg_stat_reset_slru</function> ( [ <parameter>target</parameter> <type>text</type> <literal>DEFAULT</literal> <literal>NULL</literal> ] )
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<returnvalue>void</returnvalue>
</para>
<para>
Resets statistics to zero for a single SLRU cache, or for all SLRUs in
Add support for pg_stat_reset_slru without argument pg_stat_reset_slru currently requires an input argument, either: - NULL to reset the SLRU counters of everything. - A specific value to reset a single SLRU cache. This commit adds support for a new pattern: pg_stat_reset_slru without any argument works the same way as pg_stat_reset_slru(NULL), relying on a DEFAULT in the function definition to handle this case. This makes the function more consistent with 23c8c0c8f472. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Atsushi Torikoshi Discussion: https://postgr.es/m/CALj2ACW1VizYg01EeH_cA-7qA+4NzWVAoZ5Lw9_XYO1RRHAZbA@mail.gmail.com
2023-11-14 01:50:52 +01:00
the cluster. If <parameter>target</parameter> is
<literal>NULL</literal> or is not specified, all the counters shown in
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
the <structname>pg_stat_slru</structname> view for all SLRU caches are
Add support for pg_stat_reset_slru without argument pg_stat_reset_slru currently requires an input argument, either: - NULL to reset the SLRU counters of everything. - A specific value to reset a single SLRU cache. This commit adds support for a new pattern: pg_stat_reset_slru without any argument works the same way as pg_stat_reset_slru(NULL), relying on a DEFAULT in the function definition to handle this case. This makes the function more consistent with 23c8c0c8f472. Bump catalog version. Author: Bharath Rupireddy Reviewed-by: Atsushi Torikoshi Discussion: https://postgr.es/m/CALj2ACW1VizYg01EeH_cA-7qA+4NzWVAoZ5Lw9_XYO1RRHAZbA@mail.gmail.com
2023-11-14 01:50:52 +01:00
reset. The argument can be one of
Rename SLRU elements in view pg_stat_slru The new names are intended to match those in an upcoming patch that adds a few GUCs to configure the SLRU buffer sizes. Backwards compatibility concern: this changes the accepted names for function pg_stat_slru_rest(). Since this function recognizes "any other string" as a request to reset the entry for "other", this means that calling it with the old names would silently reset "other" instead of doing nothing or throwing an error. Reviewed-by: Andrey M. Borodin <x4mmm@yandex-team.ru> Discussion: https://postgr.es/m/202402261616.dlriae7b6emv@alvherre.pgsql
2024-02-28 09:39:52 +01:00
<literal>commit_timestamp</literal>,
<literal>multixact_member</literal>,
<literal>multixact_offset</literal>,
<literal>notify</literal>,
<literal>serializable</literal>,
<literal>subtransaction</literal>, or
<literal>transaction</literal>
Rename SLRU structures and associated LWLocks. Originally, the names assigned to SLRUs had no purpose other than being shmem lookup keys, so not a lot of thought went into them. As of v13, though, we're exposing them in the pg_stat_slru view and the pg_stat_reset_slru function, so it seems advisable to take a bit more care. Rename them to names based on the associated on-disk storage directories (which fortunately we *did* think about, to some extent; since those are also visible to DBAs, consistency seems like a good thing). Also rename the associated LWLocks, since those names are likewise user-exposed now as wait event names. For the most part I only touched symbols used in the respective modules' SimpleLruInit() calls, not the names of other related objects. This renaming could have been taken further, and maybe someday we will do so. But for now it seems undesirable to change the names of any globally visible functions or structs, so some inconsistency is unavoidable. (But I *did* terminate "oldserxid" with prejudice, as I found that name both unreadable and not descriptive of the SLRU's contents.) Table 27.12 needs re-alphabetization now, but I'll leave that till after the other LWLock renamings I have in mind. Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
2020-05-15 20:28:19 +02:00
to reset the counters for only that entry.
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
If the argument is <literal>other</literal> (or indeed, any
unrecognized name), then the counters for all other SLRU caches, such
as extension-defined caches, are reset.
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
</para></entry>
</row>
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
<row>
doc: Improve wording of section for repslot statistics This documentation has been added in 9868167, so no backpatch is needed. Author: Justin Pryzby, Michael Paquier Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2021-01-29 06:24:49 +01:00
<entry role="func_table_entry"><para role="func_signature">
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
<indexterm>
<primary>pg_stat_reset_replication_slot</primary>
</indexterm>
<function>pg_stat_reset_replication_slot</function> ( <type>text</type> )
<returnvalue>void</returnvalue>
</para>
<para>
doc: Improve wording of section for repslot statistics This documentation has been added in 9868167, so no backpatch is needed. Author: Justin Pryzby, Michael Paquier Discussion: https://postgr.es/m/20201222041153.GK30237@telsasoft.com
2021-01-29 06:24:49 +01:00
Resets statistics of the replication slot defined by the argument. If
the argument is <literal>NULL</literal>, resets statistics for all
the replication slots.
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<primary>pg_stat_reset_subscription_stats</primary>
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</indexterm>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
<function>pg_stat_reset_subscription_stats</function> ( <type>oid</type> )
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
<returnvalue>void</returnvalue>
</para>
<para>
Reconsider pg_stat_subscription_workers view. It was decided (refer to the Discussion link below) that the stats collector is not an appropriate place to store the error information of subscription workers. This patch changes the pg_stat_subscription_workers view (introduced by commit 8d74fc96db) so that it stores only statistics counters: apply_error_count and sync_error_count, and has one entry for each subscription. The removed error information such as error-XID and the error message would be stored in another way in the future which is more reliable and persistent. After removing these error details, there is no longer any relation information, so the subscription statistics are now a cluster-wide statistics. The patch also changes the view name to pg_stat_subscription_stats since the word "worker" is an implementation detail that we use one worker for one tablesync and one apply. Author: Masahiko Sawada, based on suggestions by Andres Freund Reviewed-by: Peter Smith, Haiying Tang, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/20220125063131.4cmvsxbz2tdg6g65@alap3.anarazel.de
2022-03-01 01:47:52 +01:00
Resets statistics for a single subscription shown in the
<structname>pg_stat_subscription_stats</structname> view to zero. If
the argument is <literal>NULL</literal>, reset statistics for all
subscriptions.
Add a view to show the stats of subscription workers. This commit adds a new system view pg_stat_subscription_workers, that shows information about any errors which occur during the application of logical replication changes as well as during performing initial table synchronization. The subscription statistics entries are removed when the corresponding subscription is removed. It also adds an SQL function pg_stat_reset_subscription_worker() to reset single subscription errors. The contents of this view can be used by an upcoming patch that skips the particular transaction that conflicts with the existing data on the subscriber. This view can be extended in the future to track other xact related statistics like the number of xacts committed/aborted for subscription workers. Author: Masahiko Sawada Reviewed-by: Greg Nancarrow, Hou Zhijie, Tang Haiying, Vignesh C, Dilip Kumar, Takamichi Osumi, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2021-11-30 04:24:30 +01:00
</para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
Track statistics for spilling of changes from ReorderBuffer. This adds the statistics about transactions spilled to disk from ReorderBuffer. Users can query the pg_stat_replication_slots view to check these stats and call pg_stat_reset_replication_slot to reset the stats of a particular slot. Users can pass NULL in pg_stat_reset_replication_slot to reset stats of all the slots. This commit extends the statistics collector to track this information about slots. Author: Sawada Masahiko and Amit Kapila Reviewed-by: Amit Kapila and Dilip Kumar Discussion: https://postgr.es/m/CA+fd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg@mail.gmail.com
2020-10-08 05:39:08 +02:00
</para></entry>
</row>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</tbody>
</tgroup>
</table>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
doc: warn pg_stat_reset() can cause vacuum/analyze problems The fix is to run ANALYZE. Discussion: https://postgr.es/m/YzRr+ys98UzVQJvK@momjian.us, https://postgr.es/m/flat/CAKJS1f8DTbCHf9gedU0He6ARsd58E6qOhEHM1caomqj_r9MOiQ%40mail.gmail.com, https://postgr.es/m/CAKJS1f80o98hcfSk8j%3DfdN09S7Sjz%2BvuzhEwbyQqvHJb_sZw0g%40mail.gmail.com Backpatch-through: 10
2022-10-17 21:07:03 +02:00
<warning>
<para>
Using <function>pg_stat_reset()</function> also resets counters that
autovacuum uses to determine when to trigger a vacuum or an analyze.
Resetting these counters can cause autovacuum to not perform necessary
work, which can cause problems such as table bloat or out-dated
table statistics. A database-wide <command>ANALYZE</command> is
recommended after the statistics have been reset.
</para>
</warning>
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
<para>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
<function>pg_stat_get_activity</function>, the underlying function of
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
the <structname>pg_stat_activity</structname> view, returns a set of records
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
containing all the available information about each backend process.
Sometimes it may be more convenient to obtain just a subset of this
Use actual backend IDs in pg_stat_get_backend_idset() and friends. Up to now, the ID values returned by pg_stat_get_backend_idset() and used by pg_stat_get_backend_activity() and allied functions were just indexes into a local array of sessions seen by the last stats refresh. This is problematic for a few reasons. The "ID" of a session can vary over its existence, which is surprising. Also, while these numbers often match the "backend ID" used for purposes like temp schema assignment, that isn't reliably true. We can fairly cheaply switch things around to make these numbers actually be the sessions' backend IDs. The added test case illustrates that with this definition, the temp schema used by a given session can be obtained given its PID. While here, delete some dead code that guarded against getting a NULL return from pgstat_fetch_stat_local_beentry(). That can't happen as long as the caller is careful to pass an in-range array index, as all the callers are. (This code may not have been dead when written, but it surely is now.) Nathan Bossart Discussion: https://postgr.es/m/20220815205811.GA250990@nathanxps13
2022-09-29 18:14:39 +02:00
information. In such cases, another set of per-backend statistics
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
access functions can be used; these are shown in <xref
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
linkend="monitoring-stats-backend-funcs-table"/>.
Use actual backend IDs in pg_stat_get_backend_idset() and friends. Up to now, the ID values returned by pg_stat_get_backend_idset() and used by pg_stat_get_backend_activity() and allied functions were just indexes into a local array of sessions seen by the last stats refresh. This is problematic for a few reasons. The "ID" of a session can vary over its existence, which is surprising. Also, while these numbers often match the "backend ID" used for purposes like temp schema assignment, that isn't reliably true. We can fairly cheaply switch things around to make these numbers actually be the sessions' backend IDs. The added test case illustrates that with this definition, the temp schema used by a given session can be obtained given its PID. While here, delete some dead code that guarded against getting a NULL return from pgstat_fetch_stat_local_beentry(). That can't happen as long as the caller is careful to pass an in-range array index, as all the callers are. (This code may not have been dead when written, but it surely is now.) Nathan Bossart Discussion: https://postgr.es/m/20220815205811.GA250990@nathanxps13
2022-09-29 18:14:39 +02:00
These access functions use the session's backend ID number, which is a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
small integer (>= 0) that is distinct from the backend ID of any
Use actual backend IDs in pg_stat_get_backend_idset() and friends. Up to now, the ID values returned by pg_stat_get_backend_idset() and used by pg_stat_get_backend_activity() and allied functions were just indexes into a local array of sessions seen by the last stats refresh. This is problematic for a few reasons. The "ID" of a session can vary over its existence, which is surprising. Also, while these numbers often match the "backend ID" used for purposes like temp schema assignment, that isn't reliably true. We can fairly cheaply switch things around to make these numbers actually be the sessions' backend IDs. The added test case illustrates that with this definition, the temp schema used by a given session can be obtained given its PID. While here, delete some dead code that guarded against getting a NULL return from pgstat_fetch_stat_local_beentry(). That can't happen as long as the caller is careful to pass an in-range array index, as all the callers are. (This code may not have been dead when written, but it surely is now.) Nathan Bossart Discussion: https://postgr.es/m/20220815205811.GA250990@nathanxps13
2022-09-29 18:14:39 +02:00
concurrent session, although a session's ID can be recycled as soon as
it exits. The backend ID is used, among other things, to identify the
session's temporary schema if it has one.
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
The function <function>pg_stat_get_backend_idset</function> provides a
Use actual backend IDs in pg_stat_get_backend_idset() and friends. Up to now, the ID values returned by pg_stat_get_backend_idset() and used by pg_stat_get_backend_activity() and allied functions were just indexes into a local array of sessions seen by the last stats refresh. This is problematic for a few reasons. The "ID" of a session can vary over its existence, which is surprising. Also, while these numbers often match the "backend ID" used for purposes like temp schema assignment, that isn't reliably true. We can fairly cheaply switch things around to make these numbers actually be the sessions' backend IDs. The added test case illustrates that with this definition, the temp schema used by a given session can be obtained given its PID. While here, delete some dead code that guarded against getting a NULL return from pgstat_fetch_stat_local_beentry(). That can't happen as long as the caller is careful to pass an in-range array index, as all the callers are. (This code may not have been dead when written, but it surely is now.) Nathan Bossart Discussion: https://postgr.es/m/20220815205811.GA250990@nathanxps13
2022-09-29 18:14:39 +02:00
convenient way to list all the active backends' ID numbers for
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
invoking these functions. For example, to show the <acronym>PID</acronym>s and
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
current queries of all backends:
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
<programlisting>
Use actual backend IDs in pg_stat_get_backend_idset() and friends. Up to now, the ID values returned by pg_stat_get_backend_idset() and used by pg_stat_get_backend_activity() and allied functions were just indexes into a local array of sessions seen by the last stats refresh. This is problematic for a few reasons. The "ID" of a session can vary over its existence, which is surprising. Also, while these numbers often match the "backend ID" used for purposes like temp schema assignment, that isn't reliably true. We can fairly cheaply switch things around to make these numbers actually be the sessions' backend IDs. The added test case illustrates that with this definition, the temp schema used by a given session can be obtained given its PID. While here, delete some dead code that guarded against getting a NULL return from pgstat_fetch_stat_local_beentry(). That can't happen as long as the caller is careful to pass an in-range array index, as all the callers are. (This code may not have been dead when written, but it surely is now.) Nathan Bossart Discussion: https://postgr.es/m/20220815205811.GA250990@nathanxps13
2022-09-29 18:14:39 +02:00
SELECT pg_stat_get_backend_pid(backendid) AS pid,
pg_stat_get_backend_activity(backendid) AS query
FROM pg_stat_get_backend_idset() AS backendid;
Make a copy-editing pass over the new documentation for statistics views. Fix a bunch of typos, improve markup, make wording more uniform, rearrange some material. No substantive changes.
2012-04-29 19:24:44 +02:00
</programlisting>
</para>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<table id="monitoring-stats-backend-funcs-table">
<title>Per-Backend Statistics Functions</title>
<tgroup cols="1">
<thead>
<row>
<entry role="func_table_entry"><para role="func_signature">
Function
</para>
<para>
Description
</para></entry>
</row>
</thead>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<tbody>
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_activity</primary>
</indexterm>
<function>pg_stat_get_backend_activity</function> ( <type>integer</type> )
<returnvalue>text</returnvalue>
</para>
<para>
Returns the text of this backend's most recent query.
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_activity_start</primary>
</indexterm>
<function>pg_stat_get_backend_activity_start</function> ( <type>integer</type> )
<returnvalue>timestamp with time zone</returnvalue>
</para>
<para>
Returns the time when the backend's most recent query was started.
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_client_addr</primary>
</indexterm>
<function>pg_stat_get_backend_client_addr</function> ( <type>integer</type> )
<returnvalue>inet</returnvalue>
</para>
<para>
Returns the IP address of the client connected to this backend.
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_client_port</primary>
</indexterm>
<function>pg_stat_get_backend_client_port</function> ( <type>integer</type> )
<returnvalue>integer</returnvalue>
</para>
<para>
Returns the TCP port number that the client is using for communication.
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_dbid</primary>
</indexterm>
<function>pg_stat_get_backend_dbid</function> ( <type>integer</type> )
<returnvalue>oid</returnvalue>
</para>
<para>
Returns the OID of the database this backend is connected to.
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
doc: Re-order Table 28.35 "Per-Backend Statistics Functions" The overall order is alphabetic, but there were a few additions that didn't observe this. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 13:00:35 +01:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_idset</primary>
</indexterm>
<function>pg_stat_get_backend_idset</function> ()
<returnvalue>setof integer</returnvalue>
</para>
<para>
Returns the set of currently active backend ID numbers.
</para></entry>
</row>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_pid</primary>
</indexterm>
<function>pg_stat_get_backend_pid</function> ( <type>integer</type> )
<returnvalue>integer</returnvalue>
</para>
<para>
Returns the process ID of this backend.
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_start</primary>
</indexterm>
<function>pg_stat_get_backend_start</function> ( <type>integer</type> )
<returnvalue>timestamp with time zone</returnvalue>
</para>
<para>
Returns the time when this process was started.
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
<row>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<entry role="func_table_entry"><para role="func_signature">
Expose some information about backend subxact status. A new function pg_stat_get_backend_subxact() can be used to get information about the number of subtransactions in the cache of a particular backend and whether that cache has overflowed. This can be useful for tracking down performance problems that can result from overflowed snapshots. Dilip Kumar, reviewed by Zhihong Yu, Nikolay Samokhvalov, Justin Pryzby, Nathan Bossart, Ashutosh Sharma, Julien Rouhaud. Additional design comments from Andres Freund, Tom Lane, Bruce Momjian, and David G. Johnston. Discussion: http://postgr.es/m/CAFiTN-ut0uwkRJDQJeDPXpVyTWD46m3gt3JDToE02hTfONEN=Q@mail.gmail.com
2022-12-19 20:43:09 +01:00
<indexterm>
<primary>pg_stat_get_backend_subxact</primary>
</indexterm>
<function>pg_stat_get_backend_subxact</function> ( <type>integer</type> )
<returnvalue>record</returnvalue>
</para>
<para>
Returns a record of information about the subtransactions of the
backend with the specified ID.
The fields returned are <parameter>subxact_count</parameter>, which
is the number of subtransactions in the backend's subtransaction cache,
and <parameter>subxact_overflow</parameter>, which indicates whether
the backend's subtransaction cache is overflowed or not.
</para></entry>
</row>
<row>
<entry role="func_table_entry"><para role="func_signature">
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<indexterm>
<primary>pg_stat_get_backend_userid</primary>
</indexterm>
<function>pg_stat_get_backend_userid</function> ( <type>integer</type> )
<returnvalue>oid</returnvalue>
</para>
<para>
Returns the OID of the user logged into this backend.
</para></entry>
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
</row>
First-draft release notes for Postgres 9.6. These are just of beta quality, but we're only at beta ... the section about parallel query, in particular, could doubtless use more work.
2016-05-05 19:27:59 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
doc: Re-order Table 28.35 "Per-Backend Statistics Functions" The overall order is alphabetic, but there were a few additions that didn't observe this. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 13:00:35 +01:00
<primary>pg_stat_get_backend_wait_event</primary>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</indexterm>
doc: Re-order Table 28.35 "Per-Backend Statistics Functions" The overall order is alphabetic, but there were a few additions that didn't observe this. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 13:00:35 +01:00
<function>pg_stat_get_backend_wait_event</function> ( <type>integer</type> )
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<returnvalue>text</returnvalue>
</para>
<para>
doc: Re-order Table 28.35 "Per-Backend Statistics Functions" The overall order is alphabetic, but there were a few additions that didn't observe this. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 13:00:35 +01:00
Returns the wait event name if this backend is currently waiting,
otherwise NULL. See <xref linkend="wait-event-activity-table"/> through
<xref linkend="wait-event-timeout-table"/>.
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
doc: Re-order Table 28.35 "Per-Backend Statistics Functions" The overall order is alphabetic, but there were a few additions that didn't observe this. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 13:00:35 +01:00
<primary>pg_stat_get_backend_wait_event_type</primary>
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</indexterm>
doc: Re-order Table 28.35 "Per-Backend Statistics Functions" The overall order is alphabetic, but there were a few additions that didn't observe this. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 13:00:35 +01:00
<function>pg_stat_get_backend_wait_event_type</function> ( <type>integer</type> )
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<returnvalue>text</returnvalue>
</para>
<para>
doc: Re-order Table 28.35 "Per-Backend Statistics Functions" The overall order is alphabetic, but there were a few additions that didn't observe this. Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: David G. Johnston <david.g.johnston@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 13:00:35 +01:00
Returns the wait event type name if this backend is currently waiting,
otherwise NULL. See <xref linkend="wait-event-table"/> for details.
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
</para></entry>
</row>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Doc: update remaining tables of functions/operators for new layout. This converts the contrib documentation to the new style, and mops up a couple of function tables that were outside chapter 9 in the main docs. A few contrib modules choose not to present their functions in the standard tabular format. There might be room to rethink those decisions now that the standard format is more friendly to verbose descriptions. But I have not undertaken to do that here; I just converted existing tables.
2020-05-07 20:25:18 +02:00
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
<primary>pg_stat_get_backend_xact_start</primary>
</indexterm>
<function>pg_stat_get_backend_xact_start</function> ( <type>integer</type> )
<returnvalue>timestamp with time zone</returnvalue>
</para>
<para>
Returns the time when the backend's current transaction was started.
</para></entry>
</row>
</tbody>
</tgroup>
</table>
Further editorialization on the new documentation for statistics views. Get rid of the per-column documentation of underlying functions, which did far more to clutter the view descriptions than it did to be helpful, and was rather incomplete and typo-ridden anyway. Instead suggest that people consult the definitions of the standard views to see the underlying functions. The older functions for obtaining individual facts about backends are now somewhat obsoleted by pg_stat_get_activity, which means that they are not documented by any standard view. So I put that information into a separate table. (Maybe we should just deprecate them instead?) In passing, fix a couple more documentation errors.
2012-04-29 21:35:57 +02:00
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</sect2>
</sect1>
[ Newest version of patch applied.] This patch is an updated version of the lock listing patch. I've made the following changes: - write documentation - wrap the SRF in a view called 'pg_locks': all user-level access should be done through this view - re-diff against latest CVS One thing I chose not to do is adapt the SRF to use the anonymous composite type code from Joe Conway. I'll probably do that eventually, but I'm not really convinced it's a significantly cleaner way to bootstrap SRF builtins than the method this patch uses (of course, it has other uses...) Neil Conway
2002-08-17 15:04:19 +02:00
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
<sect1 id="monitoring-locks">
<title>Viewing Locks</title>
Add/edit index entries.
2003-08-31 19:32:24 +02:00
<indexterm zone="monitoring-locks">
<primary>lock</primary>
<secondary>monitoring</secondary>
</indexterm>
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
<para>
Another useful tool for monitoring database activity is the
Document all the system views created by initdb (several of these were never documented anywhere, sigh). Centralize the detailed documentation of system views into catalogs.sgml, and provide cross-references.
2003-10-18 00:38:20 +02:00
<structname>pg_locks</structname> system table. It allows the
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
database administrator to view information about the outstanding
locks in the lock manager. For example, this capability can be used
to:
More minor updates and copy-editing.
2004-12-28 20:08:58 +01:00
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
<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>
Another big editing pass for consistent content and presentation.
2003-03-24 15:32:51 +01:00
Determine the relation in the current database with the most
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
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>
Document all the system views created by initdb (several of these were never documented anywhere, sigh). Centralize the detailed documentation of system views into catalogs.sgml, and provide cross-references.
2003-10-18 00:38:20 +02:00
Details of the <structname>pg_locks</structname> view appear in
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="view-pg-locks"/>.
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
For more information on locking and managing concurrency with
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<productname>PostgreSQL</productname>, refer to <xref linkend="mvcc"/>.
Merge documentation updates from 7.3 branch.
2002-11-11 21:14:04 +01:00
</para>
</sect1>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
<sect1 id="progress-reporting">
<title>Progress Reporting</title>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<productname>PostgreSQL</productname> has the ability to report the progress of
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
certain commands during command execution. Currently, the only commands
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
which support progress reporting are <command>ANALYZE</command>,
<command>CLUSTER</command>,
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
<command>CREATE INDEX</command>, <command>VACUUM</command>,
Report progress of COPY commands This commit introduces a view pg_stat_progress_copy, reporting progress of COPY commands. This allows rough estimates how far a running COPY progressed, with the caveat that the total number of bytes may not be available in some cases (e.g. when the input comes from the client). Author: Josef Šimánek Reviewed-by: Fujii Masao, Bharath Rupireddy, Vignesh C, Matthias van de Meent Discussion: https://postgr.es/m/CAFp7QwqMGEi4OyyaLEK9DR0+E+oK3UtA4bEjDVCa4bNkwUY2PQ@mail.gmail.com Discussion: https://postgr.es/m/CAFp7Qwr6_FmRM6pCO0x_a0mymOfX_Gg+FEKet4XaTGSW=LitKQ@mail.gmail.com
2021-01-06 21:46:26 +01:00
<command>COPY</command>,
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
and <xref linkend="protocol-replication-base-backup"/> (i.e., replication
command that <xref linkend="app-pgbasebackup"/> issues to take
a base backup).
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
This may be expanded in the future.
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
</para>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<sect2 id="analyze-progress-reporting">
<title>ANALYZE Progress Reporting</title>
doc: Add additional index entries for progress reporting views. In the docs, the index entries for progress reporting views link to the "Viewing Statistics" section, but previously they did not link to the dedicated section (e.g., "ANALYZE Progress Reporting") for each view. This was inconvenient when finding the section describing the detailed information about each view, from the index. This commit adds additional index entries linking to those dedicated sections. Author: Fujii Masao Reviewed-by: Shinya Kato Discussion: https://postgr.es/m/e49c2768-65d2-188a-5424-270fa29ccc84@oss.nttdata.com
2020-12-01 09:19:23 +01:00
<indexterm>
<primary>pg_stat_progress_analyze</primary>
</indexterm>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<para>
Whenever <command>ANALYZE</command> is running, the
<structname>pg_stat_progress_analyze</structname> view will contain a
row for each backend that is currently running that command. The tables
below describe the information that will be reported and provide
information about how to interpret it.
</para>
<table id="pg-stat-progress-analyze-view" xreflabel="pg_stat_progress_analyze">
<title><structname>pg_stat_progress_analyze</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of backend.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of the table being analyzed.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>phase</structfield> <type>text</type>
</para>
<para>
Current processing phase. See <xref linkend="analyze-phases"/>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sample_blks_total</structfield> <type>bigint</type>
</para>
<para>
Total number of heap blocks that will be sampled.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>sample_blks_scanned</structfield> <type>bigint</type>
</para>
<para>
Number of heap blocks scanned.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ext_stats_total</structfield> <type>bigint</type>
</para>
<para>
Number of extended statistics.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>ext_stats_computed</structfield> <type>bigint</type>
</para>
<para>
Number of extended statistics computed. This counter only advances
when the phase is <literal>computing extended statistics</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>child_tables_total</structfield> <type>bigint</type>
</para>
<para>
Number of child tables.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>child_tables_done</structfield> <type>bigint</type>
</para>
<para>
Number of child tables scanned. This counter only advances when the
phase is <literal>acquiring inherited sample rows</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>current_child_table_relid</structfield> <type>oid</type>
</para>
<para>
OID of the child table currently being scanned. This field is
only valid when the phase is
<literal>acquiring inherited sample rows</literal>.
</para></entry>
</row>
</tbody>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
</tgroup>
</table>
<table id="analyze-phases">
docs: make monitoring "phases" table titles consistent Reported-by: Nitin Jadhav Discussion: https://postgr.es/m/CAMm1aWbmTHwHKC2PERH0CCaFVPoxrtLeS8=wNuoge94qdSp3vA@mail.gmail.com Author: Nitin Jadhav Backpatch-through: 13
2022-07-15 02:01:11 +02:00
<title>ANALYZE Phases</title>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<tgroup cols="2">
Doc: further fooling-about with rendering of tables in PDF output. I concluded that we really just ought to force all tables in PDF output to default to "left" alignment (instead of "justify"); that is what the HTML toolchain does and that's what most people have been designing the tables to look good with. There are few if any places where "justify" produces better-looking output, and there are many where it looks horrible. So change stylesheet-fo.xsl to make that true. Also tweak column widths in a few more tables to make them look better and avoid "exceed the available area" warnings. This commit fixes basically everything that can be fixed through that approach. The remaining tables that give warnings either are scheduled for redesign as per recent discussions, or need a fundamental rethink because they Just Don't Work in a narrow view.
2020-05-06 18:23:43 +02:00
<colspec colname="col1" colwidth="1*"/>
<colspec colname="col2" colwidth="2*"/>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<thead>
Doc: Fix and tweak documentation for ANALYZE reporting The docs had some typos and grammar mistakes, and its indentation was inconsistent. Author: Amit Langote, Justin Pryzby Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com
2020-01-23 09:01:46 +01:00
<row>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<entry>Phase</entry>
<entry>Description</entry>
</row>
</thead>
Doc: Fix and tweak documentation for ANALYZE reporting The docs had some typos and grammar mistakes, and its indentation was inconsistent. Author: Amit Langote, Justin Pryzby Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com
2020-01-23 09:01:46 +01:00
<tbody>
<row>
<entry><literal>initializing</literal></entry>
<entry>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
The command is preparing to begin scanning the heap. This phase is
expected to be very brief.
Doc: Fix and tweak documentation for ANALYZE reporting The docs had some typos and grammar mistakes, and its indentation was inconsistent. Author: Amit Langote, Justin Pryzby Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com
2020-01-23 09:01:46 +01:00
</entry>
</row>
<row>
<entry><literal>acquiring sample rows</literal></entry>
<entry>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
The command is currently scanning the table given by
Doc: Fix and tweak documentation for ANALYZE reporting The docs had some typos and grammar mistakes, and its indentation was inconsistent. Author: Amit Langote, Justin Pryzby Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com
2020-01-23 09:01:46 +01:00
<structfield>relid</structfield> to obtain sample rows.
</entry>
</row>
<row>
<entry><literal>acquiring inherited sample rows</literal></entry>
<entry>
The command is currently scanning child tables to obtain sample rows.
Columns <structfield>child_tables_total</structfield>,
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
<structfield>child_tables_done</structfield>, and
Doc: Fix and tweak documentation for ANALYZE reporting The docs had some typos and grammar mistakes, and its indentation was inconsistent. Author: Amit Langote, Justin Pryzby Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com
2020-01-23 09:01:46 +01:00
<structfield>current_child_table_relid</structfield> contain the
progress information for this phase.
</entry>
</row>
<row>
<entry><literal>computing statistics</literal></entry>
<entry>
The command is computing statistics from the sample rows obtained
during the table scan.
</entry>
</row>
<row>
<entry><literal>computing extended statistics</literal></entry>
<entry>
The command is computing extended statistics from the sample rows
obtained during the table scan.
</entry>
</row>
<row>
<entry><literal>finalizing analyze</literal></entry>
<entry>
doc: Fix format, incorrect structure names and markup inconsistencies Author: Alexander Lakhin Discussion: https://postgr.es/m/a2345841-10a5-4eef-257c-02302347cf39@gmail.com Backpatch-through: 13
2020-08-22 15:26:10 +02:00
The command is updating <structname>pg_class</structname>. When this
phase is completed, <command>ANALYZE</command> will end.
Doc: Fix and tweak documentation for ANALYZE reporting The docs had some typos and grammar mistakes, and its indentation was inconsistent. Author: Amit Langote, Justin Pryzby Discussion: https://postgr.es/m/20200116151930.GM26045@telsasoft.com
2020-01-23 09:01:46 +01:00
</entry>
</row>
</tbody>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
</tgroup>
</table>
<note>
<para>
Note that when <command>ANALYZE</command> is run on a partitioned table,
Improve <xref> vs. <command> formatting in the documentation SQL commands are generally marked up as <command>, except when a link to a reference page is used using <xref>. But the latter doesn't create monospace markup, so this looks strange especially when a paragraph contains a mix of links and non-links. We considered putting <command> in the <refentrytitle> on the target side, but that creates some formatting side effects elsewhere. Generally, it seems safer to solve this on the link source side. We can't put the <xref> inside the <command>; the DTD doesn't allow this. DocBook 5 would allow the <command> to have the linkend attribute itself, but we are not there yet. So to solve this for now, convert the <xref>s to <link> plus <command>. This gives the correct look and also gives some more flexibility what we can put into the link text (e.g., subcommands or other clauses). In the future, these could then be converted to DocBook 5 style. I haven't converted absolutely all xrefs to SQL command reference pages, only those where we care about the appearance of the link text or where it was otherwise appropriate to make the appearance match a bit better. Also in some cases, the links where repetitive, so in those cases the links where just removed and replaced by a plain <command>. In cases where we just want the link and don't specifically care about the generated link text (typically phrased "for further information see <xref ...>") the xref is kept. Reported-by: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org> Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf@wibble.ilmari.org
2020-10-03 16:16:51 +02:00
all of its partitions are also recursively analyzed.
In that case, <command>ANALYZE</command>
Report progress of ANALYZE commands This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for ANALYZE. Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi, Vignesh C, Amit Langote
2020-01-15 15:02:09 +01:00
progress is reported first for the parent table, whereby its inheritance
statistics are collected, followed by that for each partition.
</para>
</note>
</sect2>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<sect2 id="cluster-progress-reporting">
<title>CLUSTER Progress Reporting</title>
<indexterm>
<primary>pg_stat_progress_cluster</primary>
</indexterm>
<para>
Whenever <command>CLUSTER</command> or <command>VACUUM FULL</command> is
running, the <structname>pg_stat_progress_cluster</structname> view will
contain a row for each backend that is currently running either command.
The tables below describe the information that will be reported and
provide information about how to interpret it.
</para>
<table id="pg-stat-progress-cluster-view" xreflabel="pg_stat_progress_cluster">
<title><structname>pg_stat_progress_cluster</structname> View</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of backend.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of the table being clustered.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>command</structfield> <type>text</type>
</para>
<para>
The command that is running. Either <literal>CLUSTER</literal> or <literal>VACUUM FULL</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>phase</structfield> <type>text</type>
</para>
<para>
Current processing phase. See <xref linkend="cluster-phases"/>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>cluster_index_relid</structfield> <type>oid</type>
</para>
<para>
If the table is being scanned using an index, this is the OID of the
index being used; otherwise, it is zero.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>heap_tuples_scanned</structfield> <type>bigint</type>
</para>
<para>
Number of heap tuples scanned.
This counter only advances when the phase is
<literal>seq scanning heap</literal>,
<literal>index scanning heap</literal>
or <literal>writing new heap</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>heap_tuples_written</structfield> <type>bigint</type>
</para>
<para>
Number of heap tuples written.
This counter only advances when the phase is
<literal>seq scanning heap</literal>,
<literal>index scanning heap</literal>
or <literal>writing new heap</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>heap_blks_total</structfield> <type>bigint</type>
</para>
<para>
Total number of heap blocks in the table. This number is reported
as of the beginning of <literal>seq scanning heap</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>heap_blks_scanned</structfield> <type>bigint</type>
</para>
<para>
Number of heap blocks scanned. This counter only advances when the
phase is <literal>seq scanning heap</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>index_rebuild_count</structfield> <type>bigint</type>
</para>
<para>
Number of indexes rebuilt. This counter only advances when the phase
is <literal>rebuilding index</literal>.
</para></entry>
</row>
</tbody>
</tgroup>
</table>
<table id="cluster-phases">
<title>CLUSTER and VACUUM FULL Phases</title>
<tgroup cols="2">
<colspec colname="col1" colwidth="1*"/>
<colspec colname="col2" colwidth="2*"/>
<thead>
<row>
<entry>Phase</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>initializing</literal></entry>
<entry>
The command is preparing to begin scanning the heap. This phase is
expected to be very brief.
</entry>
</row>
<row>
<entry><literal>seq scanning heap</literal></entry>
<entry>
The command is currently scanning the table using a sequential scan.
</entry>
</row>
<row>
<entry><literal>index scanning heap</literal></entry>
<entry>
<command>CLUSTER</command> is currently scanning the table using an index scan.
</entry>
</row>
<row>
<entry><literal>sorting tuples</literal></entry>
<entry>
<command>CLUSTER</command> is currently sorting tuples.
</entry>
</row>
<row>
<entry><literal>writing new heap</literal></entry>
<entry>
<command>CLUSTER</command> is currently writing the new heap.
</entry>
</row>
<row>
<entry><literal>swapping relation files</literal></entry>
<entry>
The command is currently swapping newly-built files into place.
</entry>
</row>
<row>
<entry><literal>rebuilding index</literal></entry>
<entry>
The command is currently rebuilding an index.
</entry>
</row>
<row>
<entry><literal>performing final cleanup</literal></entry>
<entry>
The command is performing final cleanup. When this phase is
completed, <command>CLUSTER</command>
or <command>VACUUM FULL</command> will end.
</entry>
</row>
</tbody>
</tgroup>
</table>
</sect2>
<sect2 id="copy-progress-reporting">
<title>COPY Progress Reporting</title>
<indexterm>
<primary>pg_stat_progress_copy</primary>
</indexterm>
<para>
Whenever <command>COPY</command> is running, the
<structname>pg_stat_progress_copy</structname> view will contain one row
for each backend that is currently running a <command>COPY</command> command.
The table below describes the information that will be reported and provides
information about how to interpret it.
</para>
<table id="pg-stat-progress-copy-view" xreflabel="pg_stat_progress_copy">
<title><structname>pg_stat_progress_copy</structname> View</title>
<tgroup cols="1">
<thead>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
</row>
</thead>
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of backend.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of the table on which the <command>COPY</command> command is
executed. It is set to <literal>0</literal> if copying from a
<command>SELECT</command> query.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>command</structfield> <type>text</type>
</para>
<para>
The command that is running: <literal>COPY FROM</literal>, or
<literal>COPY TO</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>type</structfield> <type>text</type>
</para>
<para>
doc: Spell I/O consistently The pg_stat_io and pg_stat_copy_progress view docs spelled "I/O" as "IO" or even "io" in some places when not referring to literal names or string values. Author: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/87fry6lx5s.fsf@wibble.ilmari.org
2024-02-06 05:29:22 +01:00
The I/O type that the data is read from or written to:
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<literal>FILE</literal>, <literal>PROGRAM</literal>,
<literal>PIPE</literal> (for <command>COPY FROM STDIN</command> and
<command>COPY TO STDOUT</command>), or <literal>CALLBACK</literal>
(used for example during the initial table synchronization in
logical replication).
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>bytes_processed</structfield> <type>bigint</type>
</para>
<para>
Number of bytes already processed by <command>COPY</command> command.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>bytes_total</structfield> <type>bigint</type>
</para>
<para>
Size of source file for <command>COPY FROM</command> command in bytes.
It is set to <literal>0</literal> if not available.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tuples_processed</structfield> <type>bigint</type>
</para>
<para>
Number of tuples already processed by <command>COPY</command> command.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tuples_excluded</structfield> <type>bigint</type>
</para>
<para>
Number of tuples not processed because they were excluded by the
<command>WHERE</command> clause of the <command>COPY</command> command.
</para></entry>
</row>
Add progress reporting of skipped tuples during COPY FROM. 9e2d870119 enabled the COPY command to skip malformed data, however there was no visibility into how many tuples were actually skipped during the COPY FROM. This commit adds a new "tuples_skipped" column to pg_stat_progress_copy view to report the number of tuples that were skipped because they contain malformed data. Bump catalog version. Author: Atsushi Torikoshi Reviewed-by: Masahiko Sawada Discussion: https://postgr.es/m/d12fd8c99adcae2744212cb23feff6ed%40oss.nttdata.com
2024-01-25 02:57:41 +01:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tuples_skipped</structfield> <type>bigint</type>
</para>
<para>
Number of tuples skipped because they contain malformed data.
This counter only advances when a value other than
<literal>stop</literal> is specified to the <literal>ON_ERROR</literal>
option.
</para></entry>
</row>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
</tbody>
</tgroup>
</table>
</sect2>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<sect2 id="create-index-progress-reporting">
<title>CREATE INDEX Progress Reporting</title>
doc: Add additional index entries for progress reporting views. In the docs, the index entries for progress reporting views link to the "Viewing Statistics" section, but previously they did not link to the dedicated section (e.g., "ANALYZE Progress Reporting") for each view. This was inconvenient when finding the section describing the detailed information about each view, from the index. This commit adds additional index entries linking to those dedicated sections. Author: Fujii Masao Reviewed-by: Shinya Kato Discussion: https://postgr.es/m/e49c2768-65d2-188a-5424-270fa29ccc84@oss.nttdata.com
2020-12-01 09:19:23 +01:00
<indexterm>
<primary>pg_stat_progress_create_index</primary>
</indexterm>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<para>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
Whenever <command>CREATE INDEX</command> or <command>REINDEX</command> is running, the
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<structname>pg_stat_progress_create_index</structname> view will contain
one row for each backend that is currently creating indexes. The tables
below describe the information that will be reported and provide information
about how to interpret it.
</para>
<table id="pg-stat-progress-create-index-view" xreflabel="pg_stat_progress_create_index">
<title><structname>pg_stat_progress_create_index</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<thead>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
</thead>
<tbody>
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Fix CREATE INDEX progress reporting for multi-level partitioning. The "partitions_total" and "partitions_done" fields were updated as though the current level of partitioning was the only one. In multi-level cases, not only could partitions_total change over the course of the command, but partitions_done could go backwards or exceed the currently-reported partitions_total. Fix by setting partitions_total to the total number of direct and indirect children once at command start, and then just incrementing partitions_done at appropriate points. Invent a new progress monitoring function "pgstat_progress_incr_param" to simplify doing the latter. We can avoid adding cost for the former when doing CREATE INDEX, because ProcessUtility already enumerates the children and it's pretty easy to pass the count down to DefineIndex. In principle the same could be done in ALTER TABLE, but that's structurally difficult; for now, just eat the cost of an extra find_all_inheritors scan in that case. Ilya Gladyshev and Justin Pryzby Discussion: https://postgr.es/m/a15f904a70924ffa4ca25c3c744cff31e0e6e143.camel@gmail.com
2023-03-25 20:33:56 +01:00
Process ID of the backend creating indexes.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of the database to which this backend is connected.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
OID of the table on which the index is being created.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>index_relid</structfield> <type>oid</type>
</para>
<para>
OID of the index being created or reindexed. During a
non-concurrent <command>CREATE INDEX</command>, this is 0.
</para></entry>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Add command column to pg_stat_progress_create_index This allows determining which command is running, similar to pg_stat_progress_cluster. Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com
2019-06-04 09:16:02 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>command</structfield> <type>text</type>
</para>
<para>
Fix CREATE INDEX progress reporting for multi-level partitioning. The "partitions_total" and "partitions_done" fields were updated as though the current level of partitioning was the only one. In multi-level cases, not only could partitions_total change over the course of the command, but partitions_done could go backwards or exceed the currently-reported partitions_total. Fix by setting partitions_total to the total number of direct and indirect children once at command start, and then just incrementing partitions_done at appropriate points. Invent a new progress monitoring function "pgstat_progress_incr_param" to simplify doing the latter. We can avoid adding cost for the former when doing CREATE INDEX, because ProcessUtility already enumerates the children and it's pretty easy to pass the count down to DefineIndex. In principle the same could be done in ALTER TABLE, but that's structurally difficult; for now, just eat the cost of an extra find_all_inheritors scan in that case. Ilya Gladyshev and Justin Pryzby Discussion: https://postgr.es/m/a15f904a70924ffa4ca25c3c744cff31e0e6e143.camel@gmail.com
2023-03-25 20:33:56 +01:00
Specific command type: <literal>CREATE INDEX</literal>,
Add command column to pg_stat_progress_create_index This allows determining which command is running, similar to pg_stat_progress_cluster. Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com
2019-06-04 09:16:02 +02:00
<literal>CREATE INDEX CONCURRENTLY</literal>,
<literal>REINDEX</literal>, or <literal>REINDEX CONCURRENTLY</literal>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Add command column to pg_stat_progress_create_index This allows determining which command is running, similar to pg_stat_progress_cluster. Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com
2019-06-04 09:16:02 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>phase</structfield> <type>text</type>
</para>
<para>
Current processing phase of index creation. See <xref linkend="create-index-phases"/>.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lockers_total</structfield> <type>bigint</type>
</para>
<para>
Total number of lockers to wait for, when applicable.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>lockers_done</structfield> <type>bigint</type>
</para>
<para>
Number of lockers already waited for.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>current_locker_pid</structfield> <type>bigint</type>
</para>
<para>
Process ID of the locker currently being waited for.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blocks_total</structfield> <type>bigint</type>
</para>
<para>
Total number of blocks to be processed in the current phase.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>blocks_done</structfield> <type>bigint</type>
</para>
<para>
Number of blocks already processed in the current phase.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tuples_total</structfield> <type>bigint</type>
</para>
<para>
Total number of tuples to be processed in the current phase.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tuples_done</structfield> <type>bigint</type>
</para>
<para>
Number of tuples already processed in the current phase.
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partitions_total</structfield> <type>bigint</type>
</para>
<para>
Fix CREATE INDEX progress reporting for multi-level partitioning. The "partitions_total" and "partitions_done" fields were updated as though the current level of partitioning was the only one. In multi-level cases, not only could partitions_total change over the course of the command, but partitions_done could go backwards or exceed the currently-reported partitions_total. Fix by setting partitions_total to the total number of direct and indirect children once at command start, and then just incrementing partitions_done at appropriate points. Invent a new progress monitoring function "pgstat_progress_incr_param" to simplify doing the latter. We can avoid adding cost for the former when doing CREATE INDEX, because ProcessUtility already enumerates the children and it's pretty easy to pass the count down to DefineIndex. In principle the same could be done in ALTER TABLE, but that's structurally difficult; for now, just eat the cost of an extra find_all_inheritors scan in that case. Ilya Gladyshev and Justin Pryzby Discussion: https://postgr.es/m/a15f904a70924ffa4ca25c3c744cff31e0e6e143.camel@gmail.com
2023-03-25 20:33:56 +01:00
Total number of partitions on which the index is to be created
or attached, including both direct and indirect partitions.
<literal>0</literal> during a <literal>REINDEX</literal>, or when
the index is not partitioned.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>partitions_done</structfield> <type>bigint</type>
</para>
<para>
Fix CREATE INDEX progress reporting for multi-level partitioning. The "partitions_total" and "partitions_done" fields were updated as though the current level of partitioning was the only one. In multi-level cases, not only could partitions_total change over the course of the command, but partitions_done could go backwards or exceed the currently-reported partitions_total. Fix by setting partitions_total to the total number of direct and indirect children once at command start, and then just incrementing partitions_done at appropriate points. Invent a new progress monitoring function "pgstat_progress_incr_param" to simplify doing the latter. We can avoid adding cost for the former when doing CREATE INDEX, because ProcessUtility already enumerates the children and it's pretty easy to pass the count down to DefineIndex. In principle the same could be done in ALTER TABLE, but that's structurally difficult; for now, just eat the cost of an extra find_all_inheritors scan in that case. Ilya Gladyshev and Justin Pryzby Discussion: https://postgr.es/m/a15f904a70924ffa4ca25c3c744cff31e0e6e143.camel@gmail.com
2023-03-25 20:33:56 +01:00
Number of partitions on which the index has already been created
or attached, including both direct and indirect partitions.
<literal>0</literal> during a <literal>REINDEX</literal>, or when
the index is not partitioned.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</row>
</tbody>
</tgroup>
</table>
<table id="create-index-phases">
doc: Clean up title case use Note: Following existing practice, titles of formalpara and step are not titlecased.
2019-09-08 10:26:35 +02:00
<title>CREATE INDEX Phases</title>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<tgroup cols="2">
Doc: further fooling-about with rendering of tables in PDF output. I concluded that we really just ought to force all tables in PDF output to default to "left" alignment (instead of "justify"); that is what the HTML toolchain does and that's what most people have been designing the tables to look good with. There are few if any places where "justify" produces better-looking output, and there are many where it looks horrible. So change stylesheet-fo.xsl to make that true. Also tweak column widths in a few more tables to make them look better and avoid "exceed the available area" warnings. This commit fixes basically everything that can be fixed through that approach. The remaining tables that give warnings either are scheduled for redesign as per recent discussions, or need a fundamental rethink because they Just Don't Work in a narrow view.
2020-05-06 18:23:43 +02:00
<colspec colname="col1" colwidth="1*"/>
<colspec colname="col2" colwidth="2*"/>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<thead>
<row>
<entry>Phase</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>initializing</literal></entry>
<entry>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<command>CREATE INDEX</command> or <command>REINDEX</command> is preparing to create the index. This
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
phase is expected to be very brief.
</entry>
</row>
<row>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<entry><literal>waiting for writers before build</literal></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<entry>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<command>CREATE INDEX CONCURRENTLY</command> or <command>REINDEX CONCURRENTLY</command> is waiting for transactions
with write locks that can potentially see the table to finish.
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
This phase is skipped when not in concurrent mode.
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
doc: Fix whitespace Author: Julien Rouhaud <rjuju123@gmail.com>
2019-04-08 22:27:35 +02:00
and <structname>current_locker_pid</structname> contain the progress
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
information for this phase.
</entry>
</row>
<row>
<entry><literal>building index</literal></entry>
<entry>
The index is being built by the access method-specific code. In this phase,
access methods that support progress reporting fill in their own progress data,
and the subphase is indicated in this column. Typically,
<structname>blocks_total</structname> and <structname>blocks_done</structname>
will contain progress data, as well as potentially
<structname>tuples_total</structname> and <structname>tuples_done</structname>.
</entry>
</row>
<row>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<entry><literal>waiting for writers before validation</literal></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<entry>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<command>CREATE INDEX CONCURRENTLY</command> or <command>REINDEX CONCURRENTLY</command> is waiting for transactions
with write locks that can potentially write into the table to finish.
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
This phase is skipped when not in concurrent mode.
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
doc: Fix whitespace Author: Julien Rouhaud <rjuju123@gmail.com>
2019-04-08 22:27:35 +02:00
and <structname>current_locker_pid</structname> contain the progress
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
information for this phase.
</entry>
</row>
<row>
<entry><literal>index validation: scanning index</literal></entry>
<entry>
<command>CREATE INDEX CONCURRENTLY</command> is scanning the index searching
for tuples that need to be validated.
This phase is skipped when not in concurrent mode.
Columns <structname>blocks_total</structname> (set to the total size of the index)
and <structname>blocks_done</structname> contain the progress information for this phase.
</entry>
</row>
<row>
<entry><literal>index validation: sorting tuples</literal></entry>
<entry>
<command>CREATE INDEX CONCURRENTLY</command> is sorting the output of the
index scanning phase.
</entry>
</row>
<row>
<entry><literal>index validation: scanning table</literal></entry>
<entry>
<command>CREATE INDEX CONCURRENTLY</command> is scanning the table
to validate the index tuples collected in the previous two phases.
This phase is skipped when not in concurrent mode.
Columns <structname>blocks_total</structname> (set to the total size of the table)
and <structname>blocks_done</structname> contain the progress information for this phase.
</entry>
</row>
<row>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<entry><literal>waiting for old snapshots</literal></entry>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
<entry>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<command>CREATE INDEX CONCURRENTLY</command> or <command>REINDEX CONCURRENTLY</command> is waiting for transactions
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
that can potentially see the table to release their snapshots. This
phase is skipped when not in concurrent mode.
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
doc: Fix whitespace Author: Julien Rouhaud <rjuju123@gmail.com>
2019-04-08 22:27:35 +02:00
and <structname>current_locker_pid</structname> contain the progress
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
information for this phase.
</entry>
</row>
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
<row>
<entry><literal>waiting for readers before marking dead</literal></entry>
<entry>
<command>REINDEX CONCURRENTLY</command> is waiting for transactions
with read locks on the table to finish, before marking the old index dead.
This phase is skipped when not in concurrent mode.
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
doc: Fix whitespace Author: Julien Rouhaud <rjuju123@gmail.com>
2019-04-08 22:27:35 +02:00
and <structname>current_locker_pid</structname> contain the progress
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
information for this phase.
</entry>
</row>
<row>
<entry><literal>waiting for readers before dropping</literal></entry>
<entry>
<command>REINDEX CONCURRENTLY</command> is waiting for transactions
with read locks on the table to finish, before dropping the old index.
This phase is skipped when not in concurrent mode.
Columns <structname>lockers_total</structname>, <structname>lockers_done</structname>
doc: Fix whitespace Author: Julien Rouhaud <rjuju123@gmail.com>
2019-04-08 22:27:35 +02:00
and <structname>current_locker_pid</structname> contain the progress
Report progress of REINDEX operations This uses the same infrastructure that the CREATE INDEX progress reporting uses. Add a column to pg_stat_progress_create_index to report the OID of the index being worked on. This was not necessary for CREATE INDEX, but it's useful for REINDEX. Also edit the phase descriptions a bit to be more consistent with the source code comments. Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com
2019-04-07 11:30:14 +02:00
information for this phase.
</entry>
</row>
Report progress of CREATE INDEX operations This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY. There are two pieces to this: one is index-AM-agnostic, and the other is AM-specific. The latter is fairly elaborate for btrees, including reportage for parallel index builds and the separate phases that btree index creation uses; other index AMs, which are much simpler in their building procedures, have simplistic reporting only, but that seems sufficient, at least for non-concurrent builds. The index-AM-agnostic part is fairly complete, providing insight into the CONCURRENTLY wait phases as well as block-based progress during the index validation table scan. (The index validation index scan requires patching each AM, which has not been included here.) Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql
2019-04-02 20:18:08 +02:00
</tbody>
</tgroup>
</table>
</sect2>
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
<sect2 id="vacuum-progress-reporting">
<title>VACUUM Progress Reporting</title>
doc: Add additional index entries for progress reporting views. In the docs, the index entries for progress reporting views link to the "Viewing Statistics" section, but previously they did not link to the dedicated section (e.g., "ANALYZE Progress Reporting") for each view. This was inconvenient when finding the section describing the detailed information about each view, from the index. This commit adds additional index entries linking to those dedicated sections. Author: Fujii Masao Reviewed-by: Shinya Kato Discussion: https://postgr.es/m/e49c2768-65d2-188a-5424-270fa29ccc84@oss.nttdata.com
2020-12-01 09:19:23 +01:00
<indexterm>
<primary>pg_stat_progress_vacuum</primary>
</indexterm>
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Whenever <command>VACUUM</command> is running, the
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
<structname>pg_stat_progress_vacuum</structname> view will contain
one row for each backend (including autovacuum worker processes) that is
currently vacuuming. The tables below describe the information
that will be reported and provide information about how to interpret it.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
Progress for <command>VACUUM FULL</command> commands is reported via
<structname>pg_stat_progress_cluster</structname>
doc: Fix whitespace Author: Julien Rouhaud <rjuju123@gmail.com>
2019-04-08 22:27:35 +02:00
because both <command>VACUUM FULL</command> and <command>CLUSTER</command>
rewrite the table, while regular <command>VACUUM</command> only modifies it
Replace single-quotes with double-quotes in a few SGML attributes. Both are valid SGML, but let's be consistent. Author: Peter Smith Discussion: https://www.postgresql.org/message-id/CAHut%2BPtghjg0SBUTv%3D4Bpcy68d1zD3VAnZ3wX1DQSp39XKD9Sw%40mail.gmail.com
2023-02-27 08:55:39 +01:00
in place. See <xref linkend="cluster-progress-reporting"/>.
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
</para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<table id="pg-stat-progress-vacuum-view" xreflabel="pg_stat_progress_vacuum">
<title><structname>pg_stat_progress_vacuum</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of backend.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datid</structfield> <type>oid</type>
</para>
<para>
OID of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>datname</structfield> <type>name</type>
</para>
<para>
Name of the database to which this backend is connected.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>relid</structfield> <type>oid</type>
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
OID of the table being vacuumed.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>phase</structfield> <type>text</type>
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
Current processing phase of vacuum. See <xref linkend="vacuum-phases"/>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<structfield>heap_blks_total</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
Total number of heap blocks in the table. This number is reported
as of the beginning of the scan; blocks added later will not be (and
need not be) visited by this <command>VACUUM</command>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<structfield>heap_blks_scanned</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
Number of heap blocks scanned. Because the
<link linkend="storage-vm">visibility map</link> is used to optimize scans,
some blocks will be skipped without inspection; skipped blocks are
included in this total, so that this number will eventually become
equal to <structfield>heap_blks_total</structfield> when the vacuum is complete.
This counter only advances when the phase is <literal>scanning heap</literal>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<structfield>heap_blks_vacuumed</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
Number of heap blocks vacuumed. Unless the table has no indexes, this
counter only advances when the phase is <literal>vacuuming heap</literal>.
Blocks that contain no dead tuples are skipped, so the counter may
sometimes skip forward in large increments.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<structfield>index_vacuum_count</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
Number of completed index vacuum cycles.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<structfield>max_dead_tuples</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
Number of dead tuples that we can store before needing to perform
an index vacuum cycle, based on
<xref linkend="guc-maintenance-work-mem"/>.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<structfield>num_dead_tuples</structfield> <type>bigint</type>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para>
<para>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
Number of dead tuples collected since the last index vacuum cycle.
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</para></entry>
</row>
Report index vacuum progress. This commit adds two columns: indexes_total and indexes_processed, to pg_stat_progress_vacuum system view to show the index vacuum progress. These numbers are reported in the "vacuuming indexes" and "cleaning up indexes" phases. This uses the new parallel message type for progress reporting added by be06506e7. Bump catversion because this changes the definition of pg_stat_progress_vacuum. Author: Sami Imseih Reviewed by: Masahiko Sawada, Michael Paquier, Nathan Bossart, Andres Freund Discussion: https://www.postgresql.org/message-id/flat/5478DFCD-2333-401A-B2F0-0D186AB09228@amazon.com
2023-07-11 05:34:01 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexes_total</structfield> <type>bigint</type>
</para>
<para>
Total number of indexes that will be vacuumed or cleaned up. This
number is reported at the beginning of the
<literal>vacuuming indexes</literal> phase or the
<literal>cleaning up indexes</literal> phase.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>indexes_processed</structfield> <type>bigint</type>
</para>
<para>
Number of indexes processed. This counter only advances when the
phase is <literal>vacuuming indexes</literal> or
<literal>cleaning up indexes</literal>.
</para></entry>
</row>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
</tbody>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</tgroup>
</table>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<table id="vacuum-phases">
<title>VACUUM Phases</title>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<tgroup cols="2">
Doc: further fooling-about with rendering of tables in PDF output. I concluded that we really just ought to force all tables in PDF output to default to "left" alignment (instead of "justify"); that is what the HTML toolchain does and that's what most people have been designing the tables to look good with. There are few if any places where "justify" produces better-looking output, and there are many where it looks horrible. So change stylesheet-fo.xsl to make that true. Also tweak column widths in a few more tables to make them look better and avoid "exceed the available area" warnings. This commit fixes basically everything that can be fixed through that approach. The remaining tables that give warnings either are scheduled for redesign as per recent discussions, or need a fundamental rethink because they Just Don't Work in a narrow view.
2020-05-06 18:23:43 +02:00
<colspec colname="col1" colwidth="1*"/>
<colspec colname="col2" colwidth="2*"/>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<thead>
<row>
<entry>Phase</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>initializing</literal></entry>
<entry>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<command>VACUUM</command> is preparing to begin scanning the heap. This
phase is expected to be very brief.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</entry>
</row>
<row>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<entry><literal>scanning heap</literal></entry>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<entry>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<command>VACUUM</command> is currently scanning the heap. It will prune and
defragment each page if required, and possibly perform freezing
activity. The <structfield>heap_blks_scanned</structfield> column can be used
to monitor the progress of the scan.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</entry>
</row>
<row>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<entry><literal>vacuuming indexes</literal></entry>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<entry>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<command>VACUUM</command> is currently vacuuming the indexes. If a table has
any indexes, this will happen at least once per vacuum, after the heap
has been completely scanned. It may happen multiple times per vacuum
if <xref linkend="guc-maintenance-work-mem"/> (or, in the case of autovacuum,
<xref linkend="guc-autovacuum-work-mem"/> if set) is insufficient to store
the number of dead tuples found.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</entry>
</row>
Doc: Add missing step for pg_stat_progress_cluster There is a step to track when the new heap is written, but this was missing in the documentation. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/AT5PR8401MB06447FAE88E1592754E958B8EE640@AT5PR8401MB0644.NAMPRD84.PROD.OUTLOOK.COM Backpatch-through: 12
2019-10-28 06:23:42 +01:00
<row>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<entry><literal>vacuuming heap</literal></entry>
Doc: Add missing step for pg_stat_progress_cluster There is a step to track when the new heap is written, but this was missing in the documentation. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/AT5PR8401MB06447FAE88E1592754E958B8EE640@AT5PR8401MB0644.NAMPRD84.PROD.OUTLOOK.COM Backpatch-through: 12
2019-10-28 06:23:42 +01:00
<entry>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<command>VACUUM</command> is currently vacuuming the heap. Vacuuming the heap
is distinct from scanning the heap, and occurs after each instance of
vacuuming indexes. If <structfield>heap_blks_scanned</structfield> is less than
<structfield>heap_blks_total</structfield>, the system will return to scanning
the heap after this phase is completed; otherwise, it will begin
cleaning up indexes after this phase is completed.
Doc: Add missing step for pg_stat_progress_cluster There is a step to track when the new heap is written, but this was missing in the documentation. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/AT5PR8401MB06447FAE88E1592754E958B8EE640@AT5PR8401MB0644.NAMPRD84.PROD.OUTLOOK.COM Backpatch-through: 12
2019-10-28 06:23:42 +01:00
</entry>
</row>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<row>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<entry><literal>cleaning up indexes</literal></entry>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<entry>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<command>VACUUM</command> is currently cleaning up indexes. This occurs after
the heap has been completely scanned and all vacuuming of the indexes
and the heap has been completed.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</entry>
</row>
<row>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<entry><literal>truncating heap</literal></entry>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
<entry>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<command>VACUUM</command> is currently truncating the heap so as to return
empty pages at the end of the relation to the operating system. This
occurs after cleaning up indexes.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</entry>
</row>
<row>
<entry><literal>performing final cleanup</literal></entry>
<entry>
doc: Re-order sections of "28.4. Progress Reporting" BEFORE 28.4.1. ANALYZE Progress Reporting 28.4.2. CREATE INDEX Progress Reporting 28.4.3. VACUUM Progress Reporting 28.4.4. CLUSTER Progress Reporting 28.4.5. Base Backup Progress Reporting 28.4.6. COPY Progress Reporting AFTER 28.4.1. ANALYZE Progress Reporting 28.4.2. CLUSTER Progress Reporting 28.4.3. COPY Progress Reporting 28.4.4. CREATE INDEX Progress Reporting 28.4.5. VACUUM Progress Reporting 28.4.6. Base Backup Progress Reporting Author: Peter Smith <peter.b.smith@fujitsu.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/CAHut+Pv8Oa7v06hJb3+HzCtM2u-3oHWMdvXVHhvi7ofB83pNbg@mail.gmail.com
2022-11-25 11:50:36 +01:00
<command>VACUUM</command> is performing final cleanup. During this phase,
<command>VACUUM</command> will vacuum the free space map, update statistics
in <literal>pg_class</literal>, and report statistics to the cumulative
statistics system. When this phase is completed, <command>VACUUM</command> will end.
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
</entry>
</row>
</tbody>
</tgroup>
</table>
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
</sect2>
<sect2 id="basebackup-progress-reporting">
<title>Base Backup Progress Reporting</title>
doc: Add additional index entries for progress reporting views. In the docs, the index entries for progress reporting views link to the "Viewing Statistics" section, but previously they did not link to the dedicated section (e.g., "ANALYZE Progress Reporting") for each view. This was inconvenient when finding the section describing the detailed information about each view, from the index. This commit adds additional index entries linking to those dedicated sections. Author: Fujii Masao Reviewed-by: Shinya Kato Discussion: https://postgr.es/m/e49c2768-65d2-188a-5424-270fa29ccc84@oss.nttdata.com
2020-12-01 09:19:23 +01:00
<indexterm>
<primary>pg_stat_progress_basebackup</primary>
</indexterm>
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
<para>
Whenever an application like <application>pg_basebackup</application>
is taking a base backup, the
<structname>pg_stat_progress_basebackup</structname>
view will contain a row for each WAL sender process that is currently
Fix collection of typos and grammar mistakes in the tree, volume 2 This fixes some comments and documentation new as of Postgres 13, and is a follow-up of the work done in dd0f37e. Author: Justin Pryzby Discussion: https://postgr.es/m/20200408165653.GF2228@telsasoft.com
2020-04-14 07:45:43 +02:00
running the <command>BASE_BACKUP</command> replication command
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
and streaming the backup. The tables below describe the information
that will be reported and provide information about how to interpret it.
</para>
<table id="pg-stat-progress-basebackup-view" xreflabel="pg_stat_progress_basebackup">
<title><structname>pg_stat_progress_basebackup</structname> View</title>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tgroup cols="1">
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
<thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<row>
<entry role="catalog_table_entry"><para role="column_definition">
Column Type
</para>
<para>
Description
</para></entry>
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
</row>
</thead>
Doc: reformat catalog/view description tables. This changes our catalog and view descriptions to use a style inspired by the new format for function/operator tables: each table entry is formatted roughly like a <varlistentry>, with the column name and type on the first line and then an indented description. This provides much more room for expansive descriptions than we had before, and thereby eliminates a passel of PDF build warnings. Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us
2020-05-14 05:03:39 +02:00
<tbody>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>pid</structfield> <type>integer</type>
</para>
<para>
Process ID of a WAL sender process.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>phase</structfield> <type>text</type>
</para>
<para>
Current processing phase. See <xref linkend="basebackup-phases"/>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backup_total</structfield> <type>bigint</type>
</para>
<para>
Total amount of data that will be streamed. This is estimated and
reported as of the beginning of
<literal>streaming database files</literal> phase. Note that
this is only an approximation since the database
may change during <literal>streaming database files</literal> phase
and WAL log may be included in the backup later. This is always
the same value as <structfield>backup_streamed</structfield>
once the amount of data streamed exceeds the estimated
total size. If the estimation is disabled in
<application>pg_basebackup</application>
(i.e., <literal>--no-estimate-size</literal> option is specified),
this is <literal>NULL</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>backup_streamed</structfield> <type>bigint</type>
</para>
<para>
Amount of data streamed. This counter only advances
when the phase is <literal>streaming database files</literal> or
<literal>transferring wal files</literal>.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablespaces_total</structfield> <type>bigint</type>
</para>
<para>
Total number of tablespaces that will be streamed.
</para></entry>
</row>
<row>
<entry role="catalog_table_entry"><para role="column_definition">
<structfield>tablespaces_streamed</structfield> <type>bigint</type>
</para>
<para>
Number of tablespaces streamed. This counter only
advances when the phase is <literal>streaming database files</literal>.
</para></entry>
</row>
</tbody>
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
</tgroup>
</table>
<table id="basebackup-phases">
docs: make monitoring "phases" table titles consistent Reported-by: Nitin Jadhav Discussion: https://postgr.es/m/CAMm1aWbmTHwHKC2PERH0CCaFVPoxrtLeS8=wNuoge94qdSp3vA@mail.gmail.com Author: Nitin Jadhav Backpatch-through: 13
2022-07-15 02:01:11 +02:00
<title>Base Backup Phases</title>
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
<tgroup cols="2">
Doc: further fooling-about with rendering of tables in PDF output. I concluded that we really just ought to force all tables in PDF output to default to "left" alignment (instead of "justify"); that is what the HTML toolchain does and that's what most people have been designing the tables to look good with. There are few if any places where "justify" produces better-looking output, and there are many where it looks horrible. So change stylesheet-fo.xsl to make that true. Also tweak column widths in a few more tables to make them look better and avoid "exceed the available area" warnings. This commit fixes basically everything that can be fixed through that approach. The remaining tables that give warnings either are scheduled for redesign as per recent discussions, or need a fundamental rethink because they Just Don't Work in a narrow view.
2020-05-06 18:23:43 +02:00
<colspec colname="col1" colwidth="1*"/>
<colspec colname="col2" colwidth="2*"/>
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
<thead>
<row>
<entry>Phase</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>initializing</literal></entry>
<entry>
The WAL sender process is preparing to begin the backup.
This phase is expected to be very brief.
</entry>
</row>
<row>
<entry><literal>waiting for checkpoint to finish</literal></entry>
<entry>
The WAL sender process is currently performing
Remove exclusive backup mode Exclusive-mode backups have been deprecated since 9.6 (when non-exclusive backups were introduced) due to the issues they can cause should the system crash while one is running and generally because non-exclusive provides a much better interface. Further, exclusive backup mode wasn't really being tested (nor was most of the related code- like being able to log in just to stop an exclusive backup and the bits of the state machine related to that) and having to possibly deal with an exclusive backup and the backup_label file existing during pg_basebackup, pg_rewind, etc, added other complexities that we are better off without. This patch removes the exclusive backup mode, the various special cases for dealing with it, and greatly simplifies the online backup code and documentation. Authors: David Steele, Nathan Bossart Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/ac7339ca-3718-3c93-929f-99e725d1172c@pgmasters.net https://postgr.es/m/CAHg+QDfiM+WU61tF6=nPZocMZvHDzCK47Kneyb0ZRULYzV5sKQ@mail.gmail.com
2022-04-06 20:41:03 +02:00
<function>pg_backup_start</function> to prepare to
Copy editing: fix a bunch of misspellings and poor wording. 99% of this is docs, but also a couple of comments. No code changes. Justin Pryzby Discussion: https://postgr.es/m/20200919175804.GE30557@telsasoft.com
2020-09-21 18:43:42 +02:00
take a base backup, and waiting for the start-of-backup
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
checkpoint to finish.
</entry>
</row>
<row>
<entry><literal>estimating backup size</literal></entry>
<entry>
The WAL sender process is currently estimating the total amount
of database files that will be streamed as a base backup.
</entry>
</row>
<row>
<entry><literal>streaming database files</literal></entry>
<entry>
The WAL sender process is currently streaming database files
as a base backup.
</entry>
</row>
<row>
<entry><literal>waiting for wal archiving to finish</literal></entry>
<entry>
The WAL sender process is currently performing
Remove exclusive backup mode Exclusive-mode backups have been deprecated since 9.6 (when non-exclusive backups were introduced) due to the issues they can cause should the system crash while one is running and generally because non-exclusive provides a much better interface. Further, exclusive backup mode wasn't really being tested (nor was most of the related code- like being able to log in just to stop an exclusive backup and the bits of the state machine related to that) and having to possibly deal with an exclusive backup and the backup_label file existing during pg_basebackup, pg_rewind, etc, added other complexities that we are better off without. This patch removes the exclusive backup mode, the various special cases for dealing with it, and greatly simplifies the online backup code and documentation. Authors: David Steele, Nathan Bossart Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/ac7339ca-3718-3c93-929f-99e725d1172c@pgmasters.net https://postgr.es/m/CAHg+QDfiM+WU61tF6=nPZocMZvHDzCK47Kneyb0ZRULYzV5sKQ@mail.gmail.com
2022-04-06 20:41:03 +02:00
<function>pg_backup_stop</function> to finish the backup,
Report progress of streaming base backup. This commit adds pg_stat_progress_basebackup view that reports the progress while an application like pg_basebackup is taking a base backup. This uses the progress reporting infrastructure added by c16dc1aca5e0, adding support for streaming base backup. Bump catversion. Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi, Amit Langote, Sergei Kornilov Discussion: https://postgr.es/m/9ed8b801-8215-1f3d-62d7-65bff53f6e94@oss.nttdata.com
2020-03-03 04:03:43 +01:00
and waiting for all the WAL files required for the base backup
to be successfully archived.
If either <literal>--wal-method=none</literal> or
<literal>--wal-method=stream</literal> is specified in
<application>pg_basebackup</application>, the backup will end
when this phase is completed.
</entry>
</row>
<row>
<entry><literal>transferring wal files</literal></entry>
<entry>
The WAL sender process is currently transferring all WAL logs
generated during the backup. This phase occurs after
<literal>waiting for wal archiving to finish</literal> phase if
<literal>--wal-method=fetch</literal> is specified in
<application>pg_basebackup</application>. The backup will end
when this phase is completed.
</entry>
</row>
</tbody>
</tgroup>
</table>
Add progress reporting for CLUSTER and VACUUM FULL. This uses the same progress reporting infrastructure added in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these additional cases. We lack the ability to track the internal progress of sorts and index builds so the information reported is coarse-grained for some parts of the operation, but it still seems like a significant improvement over having nothing at all. Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair amount of polishing also by me. Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp
2019-03-25 15:59:04 +01:00
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
</sect2>
Report progress of COPY commands This commit introduces a view pg_stat_progress_copy, reporting progress of COPY commands. This allows rough estimates how far a running COPY progressed, with the caveat that the total number of bytes may not be available in some cases (e.g. when the input comes from the client). Author: Josef Šimánek Reviewed-by: Fujii Masao, Bharath Rupireddy, Vignesh C, Matthias van de Meent Discussion: https://postgr.es/m/CAFp7QwqMGEi4OyyaLEK9DR0+E+oK3UtA4bEjDVCa4bNkwUY2PQ@mail.gmail.com Discussion: https://postgr.es/m/CAFp7Qwr6_FmRM6pCO0x_a0mymOfX_Gg+FEKet4XaTGSW=LitKQ@mail.gmail.com
2021-01-06 21:46:26 +01:00
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
</sect1>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<sect1 id="dynamic-trace">
<title>Dynamic Tracing</title>
<indexterm zone="dynamic-trace">
<primary>DTrace</primary>
</indexterm>
<para>
<productname>PostgreSQL</productname> provides facilities to support
dynamic tracing of the database server. This allows an external
utility to be called at specific points in the code and thereby trace
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
execution.
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</para>
<para>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
A number of probes or trace points are already inserted into the source
code. These probes are intended to be used by database developers and
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
administrators. By default the probes are not compiled into
<productname>PostgreSQL</productname>; the user needs to explicitly tell
the configure script to make the probes available.
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</para>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<para>
doc: Update DTrace information The old web site link no longer worked, and some information was outdated.
2013-04-11 05:05:13 +02:00
Currently, the
<ulink url="https://en.wikipedia.org/wiki/DTrace">DTrace</ulink>
utility is supported, which, at the time of this writing, is available
Refer to OS X as "macOS", except for the port name which is still "darwin". We weren't terribly consistent about whether to call Apple's OS "OS X" or "Mac OS X", and the former is probably confusing to people who aren't Apple users. Now that Apple has rebranded it "macOS", follow their lead to establish a consistent naming pattern. Also, avoid the use of the ancient project name "Darwin", except as the port code name which does not seem desirable to change. (In short, this patch touches documentation and comments, but no actual code.) I didn't touch contrib/start-scripts/osx/, either. I suspect those are obsolete and due for a rewrite, anyway. I dithered about whether to apply this edit to old release notes, but those were responsible for quite a lot of the inconsistencies, so I ended up changing them too. Anyway, Apple's being ahistorical about this, so why shouldn't we be?
2016-09-25 21:40:57 +02:00
on Solaris, macOS, FreeBSD, NetBSD, and Oracle Linux. The
doc: Refresh more URLs in the docs This updates some URLs that are redirections, mostly to an equivalent using https. One URL referring to generalized partial indexes was outdated. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20200717.121308.1369606287593685396.horikyota.ntt@gmail.com Backpatch-through: 9.5
2020-07-18 15:43:35 +02:00
<ulink url="https://sourceware.org/systemtap/">SystemTap</ulink> project
doc: Update DTrace information The old web site link no longer worked, and some information was outdated.
2013-04-11 05:05:13 +02:00
for Linux provides a DTrace equivalent and can also be used. Supporting other dynamic
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
tracing utilities is theoretically possible by changing the definitions for
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
the macros in <filename>src/include/utils/probes.h</filename>.
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</para>
<sect2 id="compiling-for-trace">
Collect the bits of wisdom about dtrace installation in the installation chapter rather than scattering them across several incomplete fragments.
2006-12-02 10:29:51 +01:00
<title>Compiling for Dynamic Tracing</title>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<para>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
By default, probes are not available, so you will need to
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
explicitly tell the configure script to make the probes available
in <productname>PostgreSQL</productname>. To include DTrace support
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
specify <option>--enable-dtrace</option> to configure. See <xref
doc: Add installation instructions for building with meson Author: samay sharma <smilingsamay@gmail.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/CAJxrbywFPcgC4nP_v+HHPhaYSWX2JL8FZXY2aFOZxXxTkTJJPw@mail.gmail.com
2022-12-01 15:32:38 +01:00
linkend="configure-options-devel"/> for further information.
Fix broken markup.
2006-12-08 20:16:17 +01:00
</para>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</sect2>
<sect2 id="trace-points">
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
<title>Built-in Probes</title>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<para>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
A number of standard probes are provided in the source code,
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
as shown in <xref linkend="dtrace-probe-point-table"/>;
<xref linkend="typedefs-table"/>
Link some tables into the surrounding text by their id
2011-05-04 19:24:07 +02:00
shows the types used in the probes. More probes can certainly be
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
added to enhance <productname>PostgreSQL</productname>'s observability.
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</para>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<table id="dtrace-probe-point-table">
<title>Built-in DTrace Probes</title>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<tgroup cols="3">
Doc: further fooling-about with rendering of tables in PDF output. I concluded that we really just ought to force all tables in PDF output to default to "left" alignment (instead of "justify"); that is what the HTML toolchain does and that's what most people have been designing the tables to look good with. There are few if any places where "justify" produces better-looking output, and there are many where it looks horrible. So change stylesheet-fo.xsl to make that true. Also tweak column widths in a few more tables to make them look better and avoid "exceed the available area" warnings. This commit fixes basically everything that can be fixed through that approach. The remaining tables that give warnings either are scheduled for redesign as per recent discussions, or need a fundamental rethink because they Just Don't Work in a narrow view.
2020-05-06 18:23:43 +02:00
<colspec colname="col1" colwidth="2*"/>
<colspec colname="col2" colwidth="3*"/>
<colspec colname="col3" colwidth="3*"/>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<thead>
<row>
<entry>Name</entry>
<entry>Parameters</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<entry>Description</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
</thead>
<tbody>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>transaction-start</literal></entry>
<entry><literal>(LocalTransactionId)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires at the start of a new transaction.
Improve punctuation
2010-04-15 22:56:13 +02:00
arg0 is the transaction ID.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>transaction-commit</literal></entry>
<entry><literal>(LocalTransactionId)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a transaction completes successfully.
Improve punctuation
2010-04-15 22:56:13 +02:00
arg0 is the transaction ID.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>transaction-abort</literal></entry>
<entry><literal>(LocalTransactionId)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a transaction completes unsuccessfully.
Improve punctuation
2010-04-15 22:56:13 +02:00
arg0 is the transaction ID.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-start</literal></entry>
<entry><literal>(const char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the processing of a query is started.
arg0 is the query string.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-done</literal></entry>
<entry><literal>(const char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the processing of a query is complete.
arg0 is the query string.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-parse-start</literal></entry>
<entry><literal>(const char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the parsing of a query is started.
arg0 is the query string.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-parse-done</literal></entry>
<entry><literal>(const char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the parsing of a query is complete.
arg0 is the query string.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-rewrite-start</literal></entry>
<entry><literal>(const char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the rewriting of a query is started.
arg0 is the query string.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-rewrite-done</literal></entry>
<entry><literal>(const char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the rewriting of a query is complete.
arg0 is the query string.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-plan-start</literal></entry>
<entry><literal>()</literal></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<entry>Probe that fires when the planning of a query is started.</entry>
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-plan-done</literal></entry>
<entry><literal>()</literal></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<entry>Probe that fires when the planning of a query is complete.</entry>
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-execute-start</literal></entry>
<entry><literal>()</literal></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<entry>Probe that fires when the execution of a query is started.</entry>
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>query-execute-done</literal></entry>
<entry><literal>()</literal></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<entry>Probe that fires when the execution of a query is complete.</entry>
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>statement-status</literal></entry>
<entry><literal>(const char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires anytime the server process updates its
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structname>pg_stat_activity</structname>.<structfield>status</structfield>.
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
arg0 is the new status string.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>checkpoint-start</literal></entry>
<entry><literal>(int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a checkpoint is started.
arg0 holds the bitwise flags used to distinguish different checkpoint
types, such as shutdown, immediate or force.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>checkpoint-done</literal></entry>
<entry><literal>(int, int, int, int, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a checkpoint is complete.
(The probes listed next fire in sequence during checkpoint processing.)
arg0 is the number of buffers written. arg1 is the total number of
doc: Add some markup
2015-12-12 17:31:28 +01:00
buffers. arg2, arg3 and arg4 contain the number of WAL files added,
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
removed and recycled respectively.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>clog-checkpoint-start</literal></entry>
<entry><literal>(bool)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the CLOG portion of a checkpoint is started.
arg0 is true for normal checkpoint, false for shutdown
checkpoint.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>clog-checkpoint-done</literal></entry>
<entry><literal>(bool)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the CLOG portion of a checkpoint is
doc: Add some markup
2015-12-12 17:31:28 +01:00
complete. arg0 has the same meaning as for <literal>clog-checkpoint-start</literal>.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>subtrans-checkpoint-start</literal></entry>
<entry><literal>(bool)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the SUBTRANS portion of a checkpoint is
started.
arg0 is true for normal checkpoint, false for shutdown
checkpoint.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>subtrans-checkpoint-done</literal></entry>
<entry><literal>(bool)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the SUBTRANS portion of a checkpoint is
complete. arg0 has the same meaning as for
doc: Add some markup
2015-12-12 17:31:28 +01:00
<literal>subtrans-checkpoint-start</literal>.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>multixact-checkpoint-start</literal></entry>
<entry><literal>(bool)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the MultiXact portion of a checkpoint is
started.
arg0 is true for normal checkpoint, false for shutdown
checkpoint.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>multixact-checkpoint-done</literal></entry>
<entry><literal>(bool)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the MultiXact portion of a checkpoint is
complete. arg0 has the same meaning as for
doc: Add some markup
2015-12-12 17:31:28 +01:00
<literal>multixact-checkpoint-start</literal>.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-checkpoint-start</literal></entry>
<entry><literal>(int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the buffer-writing portion of a checkpoint
is started.
arg0 holds the bitwise flags used to distinguish different checkpoint
types, such as shutdown, immediate or force.</entry>
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-sync-start</literal></entry>
<entry><literal>(int, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when we begin to write dirty buffers during
checkpoint (after identifying which buffers must be written).
arg0 is the total number of buffers.
arg1 is the number that are currently dirty and need to be written.</entry>
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-sync-written</literal></entry>
<entry><literal>(int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires after each buffer is written during checkpoint.
arg0 is the ID number of the buffer.</entry>
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-sync-done</literal></entry>
<entry><literal>(int, int, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when all dirty buffers have been written.
arg0 is the total number of buffers.
arg1 is the number of buffers actually written by the checkpoint process.
arg2 is the number that were expected to be written (arg1 of
doc: Add some markup
2015-12-12 17:31:28 +01:00
<literal>buffer-sync-start</literal>); any difference reflects other processes flushing
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
buffers during the checkpoint.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-checkpoint-sync-start</literal></entry>
<entry><literal>()</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires after dirty buffers have been written to the
kernel, and before starting to issue fsync requests.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-checkpoint-done</literal></entry>
<entry><literal>()</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when syncing of buffers to disk is
complete.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>twophase-checkpoint-start</literal></entry>
<entry><literal>()</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the two-phase portion of a checkpoint is
started.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>twophase-checkpoint-done</literal></entry>
<entry><literal>()</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when the two-phase portion of a checkpoint is
complete.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
<row>
<entry><literal>buffer-extend-start</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int, unsigned int)</literal></entry>
<entry>Probe that fires when a relation extension starts.
arg0 contains the fork to be extended. arg1, arg2, and arg3 contain the
tablespace, database, and relation OIDs identifying the relation. arg4
is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
buffer. arg5 is the number of blocks the caller would like to extend
by.</entry>
</row>
<row>
<entry><literal>buffer-extend-done</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int, unsigned int, BlockNumber)</literal></entry>
<entry>Probe that fires when a relation extension is complete.
arg0 contains the fork to be extended. arg1, arg2, and arg3 contain the
tablespace, database, and relation OIDs identifying the relation. arg4
is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
buffer. arg5 is the number of blocks the relation was extended by, this
can be less than the number in the
<literal>buffer-extend-start</literal> due to resource
constraints. arg6 contains the BlockNumber of the first new
block.</entry>
</row>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-read-start</literal></entry>
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a buffer read is started.
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
arg0 and arg1 contain the fork and block numbers of the page.
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
identifying the relation.
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
arg5 is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-read-done</literal></entry>
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int, bool)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a buffer read is complete.
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
arg0 and arg1 contain the fork and block numbers of the page.
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
identifying the relation.
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
arg5 is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
bufmgr: Introduce infrastructure for faster relation extension The primary bottlenecks for relation extension are: 1) The extension lock is held while acquiring a victim buffer for the new page. Acquiring a victim buffer can require writing out the old page contents including possibly needing to flush WAL. 2) When extending via ReadBuffer() et al, we write a zero page during the extension, and then later write out the actual page contents. This can nearly double the write rate. 3) The existing bulk relation extension infrastructure in hio.c just amortized the cost of acquiring the relation extension lock, but none of the other costs. Unfortunately 1) cannot currently be addressed in a central manner as the callers to ReadBuffer() need to acquire the extension lock. To address that, this this commit moves the responsibility for acquiring the extension lock into bufmgr.c functions. That allows to acquire the relation extension lock for just the required time. This will also allow us to improve relation extension further, without changing callers. The reason we write all-zeroes pages during relation extension is that we hope to get ENOSPC errors earlier that way (largely works, except for CoW filesystems). It is easier to handle out-of-space errors gracefully if the page doesn't yet contain actual tuples. This commit addresses 2), by using the recently introduced smgrzeroextend(), which extends the relation, without dirtying the kernel page cache for all the extended pages. To address 3), this commit introduces a function to extend a relation by multiple blocks at a time. There are three new exposed functions: ExtendBufferedRel() for extending the relation by a single block, ExtendBufferedRelBy() to extend a relation by multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up to a certain size. To avoid duplicating code between ReadBuffer(P_NEW) and the new functions, ReadBuffer(P_NEW) now implements relation extension with ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the relation lock is already held. Note that this commit does not yet lead to a meaningful performance or scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be converted to ExtendBuffered*(), which will be done in subsequent commits. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de
2023-04-06 01:21:09 +02:00
arg6 is true if the buffer was found in the pool, false if not.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-flush-start</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires before issuing any write request for a shared
buffer.
arg0 and arg1 contain the fork and block numbers of the page.
arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
identifying the relation.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>buffer-flush-done</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a write request is complete. (Note
that this just reflects the time to pass the data to the kernel;
it's typically not actually been written to disk yet.)
doc: Add some markup
2015-12-12 17:31:28 +01:00
The arguments are the same as for <literal>buffer-flush-start</literal>.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>wal-buffer-write-dirty-start</literal></entry>
<entry><literal>()</literal></entry>
Fix typos in docs, some words were doubled. Thom Brown
2012-04-10 08:30:58 +02:00
<entry>Probe that fires when a server process begins to write a
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
dirty WAL buffer because no more WAL buffer space is available.
(If this happens often, it implies that
Convert documentation to DocBook XML Since some preparation work had already been done, the only source changes left were changing empty-element tags like <xref linkend="foo"> to <xref linkend="foo"/>, and changing the DOCTYPE. The source files are still named *.sgml, but they are actually XML files now. Renaming could be considered later. In the build system, the intermediate step to convert from SGML to XML is removed. Everything is build straight from the source files again. The OpenSP (or the old SP) package is no longer needed. The documentation toolchain instructions are updated and are much simpler now. Peter Eisentraut, Alexander Lakhin, Jürgen Purtz
2017-11-23 15:39:47 +01:00
<xref linkend="guc-wal-buffers"/> is too small.)</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>wal-buffer-write-dirty-done</literal></entry>
<entry><literal>()</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a dirty WAL buffer write is complete.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
Rename dtrace probes for ongoing xlog -> wal conversion. xlog-switch becomes wal-switch, and xlog-insert becomes wal-insert.
2017-02-09 22:40:19 +01:00
<entry><literal>wal-insert</literal></entry>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>(unsigned char, unsigned char)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a WAL record is inserted.
arg0 is the resource manager (rmid) for the record.
arg1 contains the info flags.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
Rename dtrace probes for ongoing xlog -> wal conversion. xlog-switch becomes wal-switch, and xlog-insert becomes wal-insert.
2017-02-09 22:40:19 +01:00
<entry><literal>wal-switch</literal></entry>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>()</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a WAL segment switch is requested.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>smgr-md-read-start</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when beginning to read a block from a relation.
arg0 and arg1 contain the fork and block numbers of the page.
arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
identifying the relation.
arg5 is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>smgr-md-read-done</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int, int, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a block read is complete.
arg0 and arg1 contain the fork and block numbers of the page.
arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
identifying the relation.
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
arg5 is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
arg6 is the number of bytes actually read, while arg7 is the number
Provide vectored variants of smgrread() and smgrwrite(). smgrreadv() and smgrwritev() and their md.c implementations call FileReadV() and FileWriteV(). A range of disk blocks beginning at 'blocknum' and extending for 'nblocks' can be scattered to or gathered from multiple buffers with a single system call. The traditional smgrread() and smgrwrite() functions are implemented in terms of the new functions. Later commits will introduce calls with nblocks > 1, but the following behavioral changes can be seen already: * After a short transfer we'll now retry until we eventually read 0 bytes (= EOF) or get ENOSPC, EDQUOT, EFBIG etc, where previously we would infer the reason. Retrying is consistent with xlog.c's treatment of large WAL writes, and arguably also xlog.c and fd.c's treatment of EINTR. Arbitrary short returns for larger transfers have been observed on several OSes, and might in theory also happen for transient reasons with our own pg_p*v() fallback code. * After unexpected EOF or -1, the error thrown now talks about a range even for the single block case, eg "blocks 42..42". Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6uT5TUm2gkvA@mail.gmail.com
2023-12-18 01:08:49 +01:00
requested (if these are different it indicates a short read).</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>smgr-md-write-start</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when beginning to write a block to a relation.
arg0 and arg1 contain the fork and block numbers of the page.
arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
identifying the relation.
arg5 is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>smgr-md-write-done</literal></entry>
<entry><literal>(ForkNumber, BlockNumber, Oid, Oid, Oid, int, int, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a block write is complete.
arg0 and arg1 contain the fork and block numbers of the page.
arg2, arg3, and arg4 contain the tablespace, database, and relation OIDs
identifying the relation.
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
arg5 is the ID of the backend which created the temporary relation for a
Replace BackendIds with 0-based ProcNumbers Now that BackendId was just another index into the proc array, it was redundant with the 0-based proc numbers used in other places. Replace all usage of backend IDs with proc numbers. The only place where the term "backend id" remains is in a few pgstat functions that expose backend IDs at the SQL level. Those IDs are now in fact 0-based ProcNumbers too, but the documentation still calls them "backend ids". That term still seems appropriate to describe what the numbers are, so I let it be. One user-visible effect is that pg_temp_0 is now a valid temp schema name, for backend with ProcNumber 0. Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi
2024-03-03 18:38:22 +01:00
local buffer, or <symbol>INVALID_PROC_NUMBER</symbol> (-1) for a shared buffer.
Further dtrace adjustments for the backend-IDs-in-relpath patch. Update the documentation, and back out a few ill-considered changes whose folly I failed to realize for failure to read the documentation.
2010-08-14 04:22:10 +02:00
arg6 is the number of bytes actually written, while arg7 is the number
Provide vectored variants of smgrread() and smgrwrite(). smgrreadv() and smgrwritev() and their md.c implementations call FileReadV() and FileWriteV(). A range of disk blocks beginning at 'blocknum' and extending for 'nblocks' can be scattered to or gathered from multiple buffers with a single system call. The traditional smgrread() and smgrwrite() functions are implemented in terms of the new functions. Later commits will introduce calls with nblocks > 1, but the following behavioral changes can be seen already: * After a short transfer we'll now retry until we eventually read 0 bytes (= EOF) or get ENOSPC, EDQUOT, EFBIG etc, where previously we would infer the reason. Retrying is consistent with xlog.c's treatment of large WAL writes, and arguably also xlog.c and fd.c's treatment of EINTR. Arbitrary short returns for larger transfers have been observed on several OSes, and might in theory also happen for transient reasons with our own pg_p*v() fallback code. * After unexpected EOF or -1, the error thrown now talks about a range even for the single block case, eg "blocks 42..42". Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6uT5TUm2gkvA@mail.gmail.com
2023-12-18 01:08:49 +01:00
requested (if these are different it indicates a short write).</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>sort-start</literal></entry>
Support parallel btree index builds. To make this work, tuplesort.c and logtape.c must also support parallelism, so this patch adds that infrastructure and then applies it to the particular case of parallel btree index builds. Testing to date shows that this can often be 2-3x faster than a serial index build. The model for deciding how many workers to use is fairly primitive at present, but it's better than not having the feature. We can refine it as we get more experience. Peter Geoghegan with some help from Rushabh Lathia. While Heikki Linnakangas is not an author of this patch, he wrote other patches without which this feature would not have been possible, and therefore the release notes should possibly credit him as an author of this feature. Reviewed by Claudio Freire, Heikki Linnakangas, Thomas Munro, Tels, Amit Kapila, me. Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
<entry><literal>(int, bool, int, int, bool, int)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a sort operation is started.
arg0 indicates heap, index or datum sort.
arg1 is true for unique-value enforcement.
arg2 is the number of key columns.
arg3 is the number of kilobytes of work memory allowed.
Support parallel btree index builds. To make this work, tuplesort.c and logtape.c must also support parallelism, so this patch adds that infrastructure and then applies it to the particular case of parallel btree index builds. Testing to date shows that this can often be 2-3x faster than a serial index build. The model for deciding how many workers to use is fairly primitive at present, but it's better than not having the feature. We can refine it as we get more experience. Peter Geoghegan with some help from Rushabh Lathia. While Heikki Linnakangas is not an author of this patch, he wrote other patches without which this feature would not have been possible, and therefore the release notes should possibly credit him as an author of this feature. Reviewed by Claudio Freire, Heikki Linnakangas, Thomas Munro, Tels, Amit Kapila, me. Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
arg4 is true if random access to the sort result is required.
arg5 indicates serial when <literal>0</literal>, parallel worker when
<literal>1</literal>, or parallel leader when <literal>2</literal>.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>sort-done</literal></entry>
<entry><literal>(bool, long)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a sort is complete.
arg0 is true for external sort, false for internal sort.
arg1 is the number of disk blocks used for an external sort,
or kilobytes of memory used for an internal sort.</entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lwlock-acquire</literal></entry>
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
<entry><literal>(char *, LWLockMode)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when an LWLock has been acquired.
Relax the requirement that all lwlocks be stored in a single array. This makes it possible to store lwlocks as part of some other data structure in the main shared memory segment, or in a dynamic shared memory segment. There is still a main LWLock array and this patch does not move anything out of it, but it provides necessary infrastructure for doing that in the future. This change is likely to increase the size of LWLockPadded on some platforms, especially 32-bit platforms where it was previously only 16 bytes. Patch by me. Review by Andres Freund and KaiGai Kohei.
2014-01-27 17:07:44 +01:00
arg0 is the LWLock's tranche.
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
arg1 is the requested lock mode, either exclusive or shared.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lwlock-release</literal></entry>
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
<entry><literal>(char *)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when an LWLock has been released (but note
that any released waiters have not yet been awakened).
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
arg0 is the LWLock's tranche.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lwlock-wait-start</literal></entry>
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
<entry><literal>(char *, LWLockMode)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when an LWLock was not immediately available and
a server process has begun to wait for the lock to become available.
Relax the requirement that all lwlocks be stored in a single array. This makes it possible to store lwlocks as part of some other data structure in the main shared memory segment, or in a dynamic shared memory segment. There is still a main LWLock array and this patch does not move anything out of it, but it provides necessary infrastructure for doing that in the future. This change is likely to increase the size of LWLockPadded on some platforms, especially 32-bit platforms where it was previously only 16 bytes. Patch by me. Review by Andres Freund and KaiGai Kohei.
2014-01-27 17:07:44 +01:00
arg0 is the LWLock's tranche.
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
arg1 is the requested lock mode, either exclusive or shared.</entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
</row>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lwlock-wait-done</literal></entry>
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
<entry><literal>(char *, LWLockMode)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a server process has been released from its
wait for an LWLock (it does not actually have the lock yet).
Relax the requirement that all lwlocks be stored in a single array. This makes it possible to store lwlocks as part of some other data structure in the main shared memory segment, or in a dynamic shared memory segment. There is still a main LWLock array and this patch does not move anything out of it, but it provides necessary infrastructure for doing that in the future. This change is likely to increase the size of LWLockPadded on some platforms, especially 32-bit platforms where it was previously only 16 bytes. Patch by me. Review by Andres Freund and KaiGai Kohei.
2014-01-27 17:07:44 +01:00
arg0 is the LWLock's tranche.
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
arg1 is the requested lock mode, either exclusive or shared.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lwlock-condacquire</literal></entry>
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
<entry><literal>(char *, LWLockMode)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when an LWLock was successfully acquired when the
caller specified no waiting.
Relax the requirement that all lwlocks be stored in a single array. This makes it possible to store lwlocks as part of some other data structure in the main shared memory segment, or in a dynamic shared memory segment. There is still a main LWLock array and this patch does not move anything out of it, but it provides necessary infrastructure for doing that in the future. This change is likely to increase the size of LWLockPadded on some platforms, especially 32-bit platforms where it was previously only 16 bytes. Patch by me. Review by Andres Freund and KaiGai Kohei.
2014-01-27 17:07:44 +01:00
arg0 is the LWLock's tranche.
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
arg1 is the requested lock mode, either exclusive or shared.</entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
</row>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lwlock-condacquire-fail</literal></entry>
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
<entry><literal>(char *, LWLockMode)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when an LWLock was not successfully acquired when
the caller specified no waiting.
Relax the requirement that all lwlocks be stored in a single array. This makes it possible to store lwlocks as part of some other data structure in the main shared memory segment, or in a dynamic shared memory segment. There is still a main LWLock array and this patch does not move anything out of it, but it provides necessary infrastructure for doing that in the future. This change is likely to increase the size of LWLockPadded on some platforms, especially 32-bit platforms where it was previously only 16 bytes. Patch by me. Review by Andres Freund and KaiGai Kohei.
2014-01-27 17:07:44 +01:00
arg0 is the LWLock's tranche.
Simplify LWLock tranche machinery by removing array_base/array_stride. array_base and array_stride were added so that we could identify the offset of an LWLock within a tranche, but this facility is only very marginally used apart from the main tranche. So, give every lock in the main tranche its own tranche ID and get rid of array_base, array_stride, and all that's attached. For debugging facilities (Trace_lwlocks and LWLOCK_STATS) print the pointer address of the LWLock using %p instead of the offset. This is arguably more useful, and certainly a lot cheaper. Drop the offset-within-tranche from the information reported to dtrace and from one can't-happen message inside lwlock.c. The main user-visible impact of this change is that pg_stat_activity will now report all waits for LWLocks as "LWLock" rather than reporting some as "LWLockTranche" and others as "LWLockNamed". The main motivation for this change is that the need to specify an array_base and an array_stride is awkward for parallel query. There is only a very limited supply of tranche IDs so we can't just keep allocating new ones, and if we try to use the same tranche IDs every time then we run into trouble when multiple parallel contexts are use simultaneously. So if we didn't get rid of this mechanism we'd have to make it even more complicated. By simplifying it in this way, we instead reduce the size of the generated code for lwlock.c by about 5%. Discussion: http://postgr.es/m/CA+TgmoYsFn6NUW1x0AZtupJGUAs1UDY4dJtCN47_Q6D0sP80PA@mail.gmail.com
2016-12-16 17:29:23 +01:00
arg1 is the requested lock mode, either exclusive or shared.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lock-wait-start</literal></entry>
<entry><literal>(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, LOCKMODE)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a request for a heavyweight lock (lmgr lock)
has begun to wait because the lock is not available.
arg0 through arg3 are the tag fields identifying the object being
locked. arg4 indicates the type of object being locked.
arg5 indicates the lock type being requested.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>lock-wait-done</literal></entry>
<entry><literal>(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, LOCKMODE)</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a request for a heavyweight lock (lmgr lock)
has finished waiting (i.e., has acquired the lock).
doc: Add some markup
2015-12-12 17:31:28 +01:00
The arguments are the same as for <literal>lock-wait-start</literal>.</entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><literal>deadlock-found</literal></entry>
<entry><literal>()</literal></entry>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<entry>Probe that fires when a deadlock is found by the deadlock
detector.</entry>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</row>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</tbody>
</tgroup>
</table>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
<table id="typedefs-table">
<title>Defined Types Used in Probe Parameters</title>
<tgroup cols="2">
<thead>
<row>
<entry>Type</entry>
<entry>Definition</entry>
</row>
</thead>
<tbody>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><type>LocalTransactionId</type></entry>
<entry><type>unsigned int</type></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><type>LWLockMode</type></entry>
<entry><type>int</type></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><type>LOCKMODE</type></entry>
<entry><type>int</type></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><type>BlockNumber</type></entry>
<entry><type>unsigned int</type></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><type>Oid</type></entry>
<entry><type>unsigned int</type></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><type>ForkNumber</type></entry>
<entry><type>int</type></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
<row>
doc: Add some markup
2015-12-12 17:31:28 +01:00
<entry><type>bool</type></entry>
Sync our DTrace infrastructure with c.h's definition of type bool. Since commit d26a810eb, we've defined bool as being either _Bool from <stdbool.h>, or "unsigned char"; but that commit overlooked the fact that probes.d has "#define bool char". For consistency, make it say "unsigned char" instead. This should be strictly a cosmetic change, but it seems best to be in sync. Formally, in the now-normal case where we're using <stdbool.h>, it'd be better to write "#define bool _Bool". However, then we'd need some build infrastructure to inject that configuration choice into probes.d, and it doesn't seem worth the trouble. We only use <stdbool.h> if sizeof(_Bool) is 1, so having DTrace think that bool parameters are "unsigned char" should be close enough. Back-patch to v12 where d26a810eb came in. Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
2019-11-06 17:11:40 +01:00
<entry><type>unsigned char</type></entry>
Doc patch for the recently added probes. Robert Lor
2009-03-10 01:08:28 +01:00
</row>
</tbody>
</tgroup>
</table>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</sect2>
<sect2 id="using-trace-points">
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
<title>Using Probes</title>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<para>
The example below shows a DTrace script for analyzing transaction
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
counts in the system, as an alternative to snapshotting
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<structname>pg_stat_database</structname> before and after a performance test:
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<programlisting>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
#!/usr/sbin/dtrace -qs
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
postgresql$1:::transaction-start
{
@start["Start"] = count();
self->ts = timestamp;
}
postgresql$1:::transaction-abort
{
@abort["Abort"] = count();
}
postgresql$1:::transaction-commit
/self->ts/
{
@commit["Commit"] = count();
@time["Total time (ns)"] = sum(timestamp - self->ts);
self->ts=0;
}
</programlisting>
When executed, the example D script gives output such as:
Collect the bits of wisdom about dtrace installation in the installation chapter rather than scattering them across several incomplete fragments.
2006-12-02 10:29:51 +01:00
<screen>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
# ./txn_count.d `pgrep -n postgres` or ./txn_count.d &lt;PID&gt;
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
^C
Start 71
Commit 70
Total time (ns) 2312105013
Collect the bits of wisdom about dtrace installation in the installation chapter rather than scattering them across several incomplete fragments.
2006-12-02 10:29:51 +01:00
</screen>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</para>
Add a note about SystemTap vs DTrace spelling of probe names.
2009-06-27 00:08:17 +02:00
<note>
<para>
SystemTap uses a different notation for trace scripts than DTrace does,
even though the underlying trace points are compatible. One point worth
noting is that at this writing, SystemTap scripts must reference probe
Proofreading improvements for the Administration documentation book.
2010-02-03 18:25:06 +01:00
names using double underscores in place of hyphens. This is expected to
Add a note about SystemTap vs DTrace spelling of probe names.
2009-06-27 00:08:17 +02:00
be fixed in future SystemTap releases.
</para>
</note>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<para>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
You should remember that DTrace scripts need to be carefully written and
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
debugged, otherwise the trace information collected might
be meaningless. In most cases where problems are found it is the
instrumentation that is at fault, not the underlying system. When
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
discussing information found using dynamic tracing, be sure to enclose
the script used to allow that too to be checked and discussed.
</para>
</sect2>
<sect2 id="defining-trace-points">
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
<title>Defining New Probes</title>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<para>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
New probes can be defined within the code wherever the developer
desires, though this will require a recompilation. Below are the steps
for inserting new probes:
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</para>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
<procedure>
<step>
<para>
Decide on probe names and data to be made available through the probes
</para>
</step>
<step>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Add the probe definitions to <filename>src/backend/utils/probes.d</filename>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
</para>
</step>
<step>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Include <filename>pg_trace.h</filename> if it is not already present in the
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
module(s) containing the probe points, and insert
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<literal>TRACE_POSTGRESQL</literal> probe macros at the desired locations
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
in the source code
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
</para>
</step>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
<step>
<para>
Recompile and verify that the new probes are available
</para>
</step>
</procedure>
<formalpara>
<title>Example:</title>
<para>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
Here is an example of how you would add a probe to trace all new
transactions by transaction ID.
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
</para>
</formalpara>
<procedure>
<step>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Decide that the probe will be named <literal>transaction-start</literal> and
doc: Add some markup
2015-12-12 17:31:28 +01:00
requires a parameter of type <type>LocalTransactionId</type>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
</para>
</step>
<step>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Add the probe definition to <filename>src/backend/utils/probes.d</filename>:
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<programlisting>
Fix indentation of verbatim block elements Block elements with verbatim formatting (literallayout, programlisting, screen, synopsis) should be aligned at column 0 independent of the surrounding SGML, because whitespace is significant, and indenting them creates erratic whitespace in the output. The CSS stylesheets already take care of indenting the output. Assorted markup improvements to go along with it.
2010-07-29 21:34:41 +02:00
probe transaction__start(LocalTransactionId);
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</programlisting>
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
Note the use of the double underline in the probe name. In a DTrace
script using the probe, the double underline needs to be replaced with a
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
hyphen, so <literal>transaction-start</literal> is the name to document for
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
users.
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
</para>
</step>
<step>
<para>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
At compile time, <literal>transaction__start</literal> is converted to a macro
called <literal>TRACE_POSTGRESQL_TRANSACTION_START</literal> (notice the
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
underscores are single here), which is available by including
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
<filename>pg_trace.h</filename>. Add the macro call to the appropriate location
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
in the source code. In this case, it looks like the following:
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
<programlisting>
Fix indentation of verbatim block elements Block elements with verbatim formatting (literallayout, programlisting, screen, synopsis) should be aligned at column 0 independent of the surrounding SGML, because whitespace is significant, and indenting them creates erratic whitespace in the output. The CSS stylesheets already take care of indenting the output. Assorted markup improvements to go along with it.
2010-07-29 21:34:41 +02:00
TRACE_POSTGRESQL_TRANSACTION_START(vxid.localTransactionId);
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</programlisting>
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
</para>
</step>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
<step>
<para>
After recompiling and running the new binary, check that your newly added
More fixes for 8.4 DTrace probes. Remove useless BUFFER_HIT/BUFFER_MISS probes --- the BUFFER_READ_DONE probe provides the same information and more besides. Expand the LOCK_WAIT_START/DONE probe arguments so that there's actually some chance of telling what is being waited for. Update and clean up the documentation.
2009-03-23 02:52:38 +01:00
probe is available by executing the following DTrace command. You
should see similar output:
Update documentation for recent DTrace changes. Patch from Robert Lor.
2008-03-25 23:50:27 +01:00
<screen>
# dtrace -ln transaction-start
ID PROVIDER MODULE FUNCTION NAME
18705 postgresql49878 postgres StartTransactionCommand transaction-start
18755 postgresql49877 postgres StartTransactionCommand transaction-start
18805 postgresql49876 postgres StartTransactionCommand transaction-start
18855 postgresql49875 postgres StartTransactionCommand transaction-start
18986 postgresql49873 postgres StartTransactionCommand transaction-start
</screen>
</para>
</step>
</procedure>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
<para>
There are a few things to be careful about when adding trace macros
to the C code:
<itemizedlist>
<listitem>
<para>
You should take care that the data types specified for a probe's
parameters match the data types of the variables used in the macro.
Otherwise, you will get compilation errors.
</para>
</listitem>
<listitem>
<para>
On most platforms, if <productname>PostgreSQL</productname> is
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
built with <option>--enable-dtrace</option>, the arguments to a trace
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
macro will be evaluated whenever control passes through the
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
macro, <emphasis>even if no tracing is being done</emphasis>. This is
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
usually not worth worrying about if you are just reporting the
values of a few local variables. But beware of putting expensive
function calls into the arguments. If you need to do that,
consider protecting the macro with a check to see if the trace
is actually enabled:
<programlisting>
Fix indentation of verbatim block elements Block elements with verbatim formatting (literallayout, programlisting, screen, synopsis) should be aligned at column 0 independent of the surrounding SGML, because whitespace is significant, and indenting them creates erratic whitespace in the output. The CSS stylesheets already take care of indenting the output. Assorted markup improvements to go along with it.
2010-07-29 21:34:41 +02:00
if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
TRACE_POSTGRESQL_TRANSACTION_START(some_function(...));
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
</programlisting>
Don't use SGML empty tags For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, Jürgen Purtz
2017-10-09 03:44:17 +02:00
Each trace macro has a corresponding <literal>ENABLED</literal> macro.
Add documentation of the fact that dtrace probes evaluate their parameters even when not active. Explain how to prevent that with an ENABLED() check.
2009-03-28 01:10:23 +01:00
</para>
</listitem>
</itemizedlist>
</para>
Add some documentation for DTrace support. Simon Riggs
2006-12-02 01:42:54 +01:00
</sect2>
</sect1>
Add documentation about statistics collector and stats views & functions.
2001-10-17 01:57:06 +02:00
</chapter>