database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Simplify and rename some GUC variables, per various recent discussions:

Browse Source 
* stats_start_collector goes away; we always start the collector process,
unless prevented by a problem with setting up the stats UDP socket.

* stats_reset_on_server_start goes away; it seems useless in view of the
availability of pg_stat_reset().

* stats_block_level and stats_row_level are merged into a single variable
"track_counts", which controls all reports sent to the collector process.

* stats_command_string is renamed to track_activities.

* log_autovacuum is renamed to log_autovacuum_min_duration to better reflect
its meaning.

The log_autovacuum change is not a compatibility issue since it didn't exist
before 8.3 anyway.  The other changes need to be release-noted.
This commit is contained in:
Tom Lane
2007-09-24 03:12:23 +00:00
parent 02138357ff
commit 48f7e64395
14 changed files with 182 additions and 351 deletions
Download Patch File Download Diff File Expand all files Collapse all files

150
doc/src/sgml/config.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.145 2007/09/22 19:10:44 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.146 2007/09/24 03:12:23 tgl Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -3186,30 +3186,19 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<title>Query and Index Statistics Collector</title>
<para>
These parameters control a server-wide statistics collection feature.
These parameters control server-wide statistics collection features.
When statistics collection is enabled, the data that is produced can be
accessed via the <structname>pg_stat</structname> and
<structname>pg_statio</structname> family of system views.
Refer to <xref linkend="monitoring"> for more information.
</para>
<note>
<para>
As of <productname>PostgreSQL</productname> 8.2,
<varname>stats_command_string</varname> controls a separate data
collection mechanism that can be turned on or off independently
of whether the statistics-collection subprocess is running.
The subprocess is only needed to support collection of
block-level or row-level statistics.
</para>
</note>
<variablelist>
<varlistentry id="guc-stats-command-string" xreflabel="stats_command_string">
<term><varname>stats_command_string</varname> (<type>boolean</type>)</term>
<varlistentry id="guc-track-activities" xreflabel="track_activities">
<term><varname>track_activities</varname> (<type>boolean</type>)</term>
<indexterm>
<primary><varname>stats_command_string</> configuration parameter</primary>
<primary><varname>track_activities</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
@ -3225,6 +3214,21 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</listitem>
</varlistentry>
<varlistentry id="guc-track-counts" xreflabel="track_counts">
<term><varname>track_counts</varname> (<type>boolean</type>)</term>
<indexterm>
<primary><varname>track_counts</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Enables collection of statistics on database activity.
This parameter is on by default, because the autovacuum
daemon needs the collected information.
Only superusers can change this setting.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-update-process-title" xreflabel="update_process_title">
<term><varname>update_process_title</varname> (<type>boolean</type>)</term>
<indexterm>
@ -3234,75 +3238,13 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<para>
Enables updating of the process title every time a new SQL command
is received by the server. The process title is typically viewed
by the <command>ps</> command or in Windows using the <application>Process
Explorer</>. Only superusers can change this setting.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-stats-start-collector" xreflabel="stats_start_collector">
<term><varname>stats_start_collector</varname> (<type>boolean</type>)</term>
<indexterm>
<primary><varname>stats_start_collector</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Controls whether the server should start the
statistics-collection subprocess. This is on by default, but
can be turned off if you know you have no interest in
collecting statistics or running autovacuum.
This parameter can only be set at server start, because the collection
subprocess cannot be started or stopped on-the-fly. (However, the
extent to which statistics are actually gathered can be changed while
the server is running, so long as the subprocess exists.)
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-stats-block-level" xreflabel="stats_block_level">
<term><varname>stats_block_level</varname> (<type>boolean</type>)</term>
<indexterm>
<primary><varname>stats_block_level</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Enables the collection of block-level statistics on database
activity. This parameter is off by default.
by the <command>ps</> command,
or in Windows by using the <application>Process Explorer</>.
Only superusers can change this setting.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-stats-row-level" xreflabel="stats_row_level">
<term><varname>stats_row_level</varname> (<type>boolean</type>)</term>
<indexterm>
<primary><varname>stats_row_level</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Enables the collection of row-level statistics on database
activity. This parameter is on by default, because the autovacuum
daemon needs the collected information.
Only superusers can change this setting.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-stats-reset-on-server-start" xreflabel="stats_reset_on_server_start">
<term><varname>stats_reset_on_server_start</varname> (<type>boolean</type>)</term>
<indexterm>
<primary><varname>stats_reset_on_server_start</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
If on, collected block-level and row-level statistics are zeroed out
whenever the server is restarted. If off, statistics are accumulated
across server restarts. This parameter is off by default.
This parameter can only be set at server start.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
@ -3369,21 +3311,40 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<listitem>
<para>
Controls whether the server should run the
autovacuum launcher daemon. This is on by default.
<varname>stats_start_collector</> and <varname>stats_row_level</>
must also be turned on for autovacuum to work.
autovacuum launcher daemon. This is on by default; however,
<xref linkend="guc-track-counts"> must also be turned on for
autovacuum to work.
This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.
</para>
<para>
Note that even when this parameter is disabled, the system
will periodically launch autovacuum processes in order to
will launch autovacuum processes if necessary to
prevent transaction ID wraparound. See <xref
linkend="vacuum-for-wraparound"> for more information.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-log-autovacuum-min-duration" xreflabel="log_autovacuum_min_duration">
<term><varname>log_autovacuum_min_duration</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>log_autovacuum_min_duration</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Causes each action executed by autovacuum to be logged if it ran for at
least the specified number of milliseconds. Setting this to zero logs
all autovacuum actions. Minus-one (the default) disables logging
autovacuum actions. For example, if you set this to
<literal>250ms</literal> then all automatic vacuums and analyzes that run
250ms or longer will be logged. Enabling this parameter can be helpful
in tracking autovacuum activity. This setting can only be set in
the <filename>postgresql.conf</> file or on the server command line.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-autovacuum-max-workers" xreflabel="autovacuum_max_workers">
<term><varname>autovacuum_max_workers</varname> (<type>integer</type>)</term>
<indexterm>
@ -3393,26 +3354,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<para>
Specifies the maximum number of autovacuum processes (other than the
autovacuum launcher) which may be running at any one time. The default
is three (<literal>3</literal>). This parameter can only be set in
the <filename>postgresql.conf</> file or on the server command line.
</para>
</listitem>
</varlistentry>
<varlistentry id="guc-log-autovacuum" xreflabel="log_autovacuum">
<term><varname>log_autovacuum</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>log_autovacuum</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
Causes each action executed by autovacuum to be logged if it ran for at
least the specified number of milliseconds. Setting this to zero logs
all autovacuum actions. Minus-one (the default) disables logging
autovacuum actions. For example, if you set this to
<literal>250ms</literal> then all vacuums and analyzes that run
250ms or longer will be logged. Enabling this parameter can be helpful
in tracking autovacuum activity. This setting can only be set in
is three. This parameter can only be set in
the <filename>postgresql.conf</> file or on the server command line.
</para>
</listitem>

17
doc/src/sgml/maintenance.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.81 2007/09/14 13:43:03 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.82 2007/09/24 03:12:23 tgl Exp $ -->
<chapter id="maintenance">
<title>Routine Database Maintenance Tasks</title>
@ -203,7 +203,7 @@
</sect2>
<sect2 id="vacuum-for-statistics">
<title>Updating planner statistics</title>
<title>Updating Planner Statistics</title>
<indexterm zone="vacuum-for-statistics">
<primary>statistics</primary>
@ -279,7 +279,7 @@
</sect2>
<sect2 id="vacuum-for-wraparound">
<title>Preventing transaction ID wraparound failures</title>
<title>Preventing Transaction ID Wraparound Failures</title>
<indexterm zone="vacuum-for-wraparound">
<primary>transaction ID</primary>
@ -460,7 +460,7 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
</sect2>
<sect2 id="autovacuum">
<title id="autovacuum-title">The auto-vacuum daemon</title>
<title id="autovacuum-title">The Auto-Vacuum Daemon</title>
<indexterm>
<primary>autovacuum</primary>
@ -473,10 +473,9 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
<command>VACUUM</command> and <command>ANALYZE </command> commands.
When enabled, autovacuum checks for
tables that have had a large number of inserted, updated or deleted
tuples. These checks use the row-level statistics collection facility;
tuples. These checks use the statistics collection facility;
therefore, autovacuum cannot be used unless <xref
linkend="guc-stats-start-collector"> and <xref
linkend="guc-stats-row-level"> are set to <literal>true</literal>.
linkend="guc-track-counts"> is set to <literal>true</literal>.
In the default configuration, autovacuuming is enabled and the related
configuration parameters are appropriately set.
</para>
@ -497,8 +496,8 @@ HINT: Stop the postmaster and use a standalone backend to VACUUM in "mydb".
eligible for vacuuming in a short amount of time, all autovacuum workers
may end up vacuuming those tables for a very long time. This would result
in other tables and databases not being vacuumed until a worker became
available. There is also not a limit on how many workers might be in a
single database, but workers do try and avoid repeating work that has
available. There is not a limit on how many workers might be in a
single database, but workers do try to avoid repeating work that has
already been done by other workers. Note that the number of running
workers does not count towards the <xref linkend="guc-max-connections"> nor
the <xref linkend="guc-superuser-reserved-connections"> limits.

48
doc/src/sgml/monitoring.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.52 2007/09/20 17:56:30 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.53 2007/09/24 03:12:23 tgl Exp $ -->
<chapter id="monitoring">
<title>Monitoring Database Activity</title>
@ -117,14 +117,15 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<productname>PostgreSQL</productname>'s <firstterm>statistics collector</>
is a subsystem that supports collection and reporting of information about
server activity. Presently, the collector can count accesses to tables
and indexes in both disk-block and individual-row terms.
and indexes in both disk-block and individual-row terms. It also tracks
total numbers of rows in each table, and the last vacuum and analyze times
for each table.
</para>
<para>
<productname>PostgreSQL</productname> also supports determining the exact
command currently being executed by other server processes. This is an
independent facility that can be enabled or disabled whether or not
block-level and row-level statistics are being collected.
independent facility that does not depend on the collector process.
</para>
<sect2 id="monitoring-stats-setup">
@ -139,31 +140,14 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
</para>
<para>
The parameter <xref linkend="guc-stats-start-collector"> must be
set to <literal>true</> for the statistics collector to be launched
at all. This is the default and recommended setting, but it can be
turned off if you have no interest in statistics and want to
squeeze out every last drop of overhead. (The savings is likely to
be small, however.) Note that this option cannot be changed while
the server is running.
The parameter <xref linkend="guc-track-counts"> controls whether
information is actually sent to the collector process and thus determines
whether any run-time overhead occurs for event counting.
</para>
<para>
The parameters <xref linkend="guc-stats-block-level"> and <xref
linkend="guc-stats-row-level"> control how much information is
actually sent to the collector and thus determine how much run-time
overhead occurs. These respectively determine whether a server
process tracks disk-block-level access
statistics and row-level access statistics and sends these to the collector.
Additionally, per-database transaction commit and abort statistics
are collected if either of these parameters are set.
</para>
<para>
The parameter <xref linkend="guc-stats-command-string"> enables monitoring
The parameter <xref linkend="guc-track-activities"> enables monitoring
of the current command being executed by any server process.
The statistics collector subprocess need not be running to enable this
feature.
</para>
<para>
@ -190,13 +174,13 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
<para>
When using the statistics to monitor current activity, it is important
to realize that the information does not update instantaneously.
Each individual server process transmits new block and row access counts to
Each individual server process transmits new statistical counts to
the collector just before going idle; so a query or transaction still in
progress does not affect the displayed totals. Also, the collector itself
emits a new report at most once per <varname>PGSTAT_STAT_INTERVAL</varname>
milliseconds (500 unless altered while building the server). So the
displayed information lags behind actual activity. However, current-query
information collected by <varname>stats_command_string</varname> is
information collected by <varname>track_activities</varname> is
always up-to-date.
</para>
@ -240,7 +224,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
current query began execution, time at which the process was
started, and client's address and port number. The columns that
report data on the current query are available unless the parameter
<varname>stats_command_string</varname> has been turned off.
<varname>track_activities</varname> has been turned off.
Furthermore, these columns are only visible if the user examining
the view is a superuser or the same as the user owning the process
being reported on.
@ -715,7 +699,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
Active command of the given server process, but only if the
current user is a superuser or the same user as that of
the session being queried (and
<varname>stats_command_string</varname> is on)
<varname>track_activities</varname> is on)
</entry>
</row>
@ -726,7 +710,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
True if the given server process is waiting for a lock,
but only if the current user is a superuser or the same user as that of
the session being queried (and
<varname>stats_command_string</varname> is on)
<varname>track_activities</varname> is on)
</entry>
</row>
@ -738,7 +722,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
executing query was started, but only if the
current user is a superuser or the same user as that of
the session being queried (and
<varname>stats_command_string</varname> is on)
<varname>track_activities</varname> is on)
</entry>
</row>
@ -750,7 +734,7 @@ postgres: <replaceable>user</> <replaceable>database</> <replaceable>host</> <re
executing transaction was started, but only if the
current user is a superuser or the same user as that of
the session being queried (and
<varname>stats_command_string</varname> is on)
<varname>track_activities</varname> is on)
</entry>
</row>

5
doc/src/sgml/release.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.507 2007/09/16 03:03:00 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/release.sgml,v 1.508 2007/09/24 03:12:23 tgl Exp $ -->
<!--
Typical markup:
@ -1475,8 +1475,7 @@ do it for earlier branch release files.
<listitem>
<para>
Improve performance of statistics monitoring, especially
<link
linkend="guc-stats-command-string"><varname>stats_command_string</></link>
<varname>stats_command_string</>
(Tom, Bruce)
</para>