Add delay time to VACUUM/ANALYZE (VERBOSE) and autovacuum logs.
authorNathan Bossart <[email protected]>
Fri, 14 Feb 2025 20:53:28 +0000 (14:53 -0600)
committerNathan Bossart <[email protected]>
Fri, 14 Feb 2025 20:53:28 +0000 (14:53 -0600)
Commit bb8dff9995 added this information to the
pg_stat_progress_vacuum and pg_stat_progress_analyze system views.
This commit adds the same information to the output of VACUUM and
ANALYZE with the VERBOSE option and to the autovacuum logs.

Suggested-by: Masahiro Ikeda <[email protected]>
Author: Bertrand Drouvot <[email protected]>
Discussion: https://postgr.es/m/ZmaXmWDL829fzAVX%40ip-10-97-1-34.eu-west-3.compute.internal

doc/src/sgml/config.sgml
src/backend/access/heap/vacuumlazy.c
src/backend/commands/analyze.c

index 5e4f201e09956df0d69f722c058532b7bc408bad..60829b79d83b0cd2ed6e3a2c9fa2fd9a77bf79e2 100644 (file)
@@ -8267,9 +8267,12 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
         platforms.  You can use the <xref linkend="pgtesttiming"/> tool to
         measure the overhead of timing on your system.  Cost-based vacuum delay
         timing information is displayed in
-        <link linkend="vacuum-progress-reporting"><structname>pg_stat_progress_vacuum</structname></link>
-        and
-        <link linkend="analyze-progress-reporting"><structname>pg_stat_progress_analyze</structname></link>.
+        <link linkend="vacuum-progress-reporting"><structname>pg_stat_progress_vacuum</structname></link>,
+        <link linkend="analyze-progress-reporting"><structname>pg_stat_progress_analyze</structname></link>,
+        in the output of <xref linkend="sql-vacuum"/> when the
+        <literal>VERBOSE</literal> option is used, and by autovacuum for
+        auto-vacuums and auto-analyzes when
+        <xref linkend="guc-log-autovacuum-min-duration"/> is set.
         Only superusers and users with the appropriate <literal>SET</literal>
         privilege can change this setting.
        </para>
index 74175e00534db416da90f81c0e34672156ba4942..a231854b1e6e97d2984e8f467426fee07f12a1da 100644 (file)
@@ -1091,6 +1091,17 @@ heap_vacuum_rel(Relation rel, VacuumParams *params,
                                 istat->pages_deleted,
                                 istat->pages_free);
            }
+           if (track_cost_delay_timing)
+           {
+               /*
+                * We bypass the changecount mechanism because this value is
+                * only updated by the calling process.  We also rely on the
+                * above call to pgstat_progress_end_command() to not clear
+                * the st_progress_param array.
+                */
+               appendStringInfo(&buf, _("delay time: %.3f ms\n"),
+                                (double) MyBEEntry->st_progress_param[PROGRESS_VACUUM_DELAY_TIME] / 1000000.0);
+           }
            if (track_io_timing)
            {
                double      read_ms = (double) (pgStatBlockReadTime - startreadtime) / 1000;
index e4302f4cdb286881722af1311707774461129b95..5931d47fdb9f5f9629cefbf7aa777d722d81ca64 100644 (file)
@@ -808,6 +808,15 @@ do_analyze_rel(Relation onerel, VacuumParams *params,
                             get_database_name(MyDatabaseId),
                             get_namespace_name(RelationGetNamespace(onerel)),
                             RelationGetRelationName(onerel));
+           if (track_cost_delay_timing)
+           {
+               /*
+                * We bypass the changecount mechanism because this value is
+                * only updated by the calling process.
+                */
+               appendStringInfo(&buf, _("delay time: %.3f ms\n"),
+                                (double) MyBEEntry->st_progress_param[PROGRESS_ANALYZE_DELAY_TIME] / 1000000.0);
+           }
            if (track_io_timing)
            {
                double      read_ms = (double) (pgStatBlockReadTime - startreadtime) / 1000;