Add log_autovacuum_{vacuum|analyze}_min_duration
Hi hackers,
I am proposing the introduction of two new GUC parameters,
log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing
log_autovacuum_min_duration.
Motivation:
Currently, log_autovacuum_min_duration controls the logging threshold
for both autovacuum and autoanalyze activities. However, autoanalyze
operations typically have a much shorter duration than autovacuum
operations. Consequently, if log_autovacuum_min_duration is set to a
value appropriate for capturing longer-running autovacuum tasks,
shorter autoanalyze activities are often not logged. This can make it
difficult to monitor and troubleshoot autoanalyze behavior
effectively.
By providing separate GUCs, administrators can set distinct logging
thresholds for autovacuum and autoanalyze, ensuring that both types of
activities can be logged appropriately based on their typical
execution times.
Example Usage:
The following SQL demonstrates how these new parameters would allow
for more granular logging. In this example, autoanalyze is configured
to always log (duration set to 0), while autovacuum is set to log only
if it runs for a very long time.
```
=# CREATE TABLE t (i int, d text) WITH (
-- autoanalyze settings
autovacuum_analyze_threshold = 1,
autovacuum_analyze_scale_factor = 0,
log_autovacuum_analyze_min_duration = 0,
-- autovacuum settings
autovacuum_vacuum_threshold = 1,
autovacuum_vacuum_scale_factor = 0,
log_autovacuum_vacuum_min_duration = 100_000_000
);
=# INSERT INTO t VALUES (1, 'a');
=# DELETE FROM t WHERE i = 1;
2025-06-03 15:15:39.608 JST [401368] LOG: automatic analyze of table
"postgres.public.t"
avg read rate: 18.229 MB/s, avg write rate: 0.000 MB/s
buffer usage: 155 hits, 7 reads, 0 dirtied
WAL usage: 1 records, 0 full page images, 530 bytes, 0 buffers full
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
```
Two patches are attached.
In v1-0001-Rename-log_autovacuum_min_duration.patch, just renamed
log_autovacuum_min_duration to log_autovacuum_vacuum_min_duration.
In v1-0002-Add-log_autovacuum_analyze_min_duration.patch, add the new
GUC parameter log_autovacuum_analyze_min_duration.
Do you think?
Best regards,
Shinya Kato
NTT OSS Center
Attachments:
v1-0002-Add-log_autovacuum_analyze_min_duration.patchapplication/octet-stream; name=v1-0002-Add-log_autovacuum_analyze_min_duration.patchDownload+100-6
v1-0001-Rename-log_autovacuum_min_duration.patchapplication/octet-stream; name=v1-0001-Rename-log_autovacuum_min_duration.patchDownload+61-61
Hi,
On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote:
I am proposing the introduction of two new GUC parameters,
log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing
log_autovacuum_min_duration.
How about adding log_autoanalyze_min_duration instead? That would still
slightly retcon the log_autovacuum_min_duration meaning/semantics by no
longer logging autoanalyze unless the new GUC is set, but at least not
rename the GUC and make both shorter while still being comprehensible
IMO. Not sure what others think?
Michael
Thank you for the comment!
On Tue, Jun 3, 2025 at 4:42 PM Michael Banck <mbanck@gmx.net> wrote:
Hi,
On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote:
I am proposing the introduction of two new GUC parameters,
log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing
log_autovacuum_min_duration.How about adding log_autoanalyze_min_duration instead? That would still
slightly retcon the log_autovacuum_min_duration meaning/semantics by no
longer logging autoanalyze unless the new GUC is set, but at least not
rename the GUC and make both shorter while still being comprehensible
IMO. Not sure what others think?
I surely think adding log_autoanalyze_min_duration is simpler and
shorter, but the reason I chose this GUC name is for consistency with
other autovacuum parameters. Existing autovacuum parameters that have
separate settings for vacuum and analyze operations follow the pattern
autovacuum_{vacuum|analyze}_*.
https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUM
Shinya Kato
NTT OSS Center
Hi,
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
On Tue, Jun 3, 2025 at 4:42 PM Michael Banck <mbanck@gmx.net> wrote:
On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote:
I am proposing the introduction of two new GUC parameters,
log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing
log_autovacuum_min_duration.How about adding log_autoanalyze_min_duration instead? That would still
slightly retcon the log_autovacuum_min_duration meaning/semantics by no
longer logging autoanalyze unless the new GUC is set, but at least not
rename the GUC and make both shorter while still being comprehensible
IMO. Not sure what others think?I surely think adding log_autoanalyze_min_duration is simpler and
shorter, but the reason I chose this GUC name is for consistency with
other autovacuum parameters. Existing autovacuum parameters that have
separate settings for vacuum and analyze operations follow the pattern
autovacuum_{vacuum|analyze}_*.
https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUM
Right, but the GUCs that directly affect either vacuum or autovacuum
behaviour need the qualification (and then vacuum/analyze on top of it).
I think we have less constraints with the logging GUC and do not need to
mirror the behaviorial GUCs at all costs. But again, that is just my two
cents.
Unless we want to have 4 logging GUCs
(log_{auto,}vacuum_{vacuum,analyze}_min_duration) which I think would
be overkill?
Michael
On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote:
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
I surely think adding log_autoanalyze_min_duration is simpler and
shorter, but the reason I chose this GUC name is for consistency with
other autovacuum parameters. Existing autovacuum parameters that have
separate settings for vacuum and analyze operations follow the pattern
autovacuum_{vacuum|analyze}_*.
https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUMRight, but the GUCs that directly affect either vacuum or autovacuum
behaviour need the qualification (and then vacuum/analyze on top of it).
I think we have less constraints with the logging GUC and do not need to
mirror the behaviorial GUCs at all costs. But again, that is just my two
cents.
I lean towards log_autovacuum_{vacuum|analyze}_min_duration. If
log_autovacuum_min_duration didn't exist, that's probably the naming scheme
we'd go with. However, I'm not sure we can get away with renaming
log_autovacuum_min_duration. Presumably we'd need to at least keep it
around as a backward-compatibility GUC, and its behavior would probably
change, too (e.g., to only logging vacuums). Maybe that's acceptable if we
buy the assertion that autoanalyze is typically much faster than autovacuum
(and so autoanalyzes weren't getting logged, anyway).
--
nathan
On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote:
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
I surely think adding log_autoanalyze_min_duration is simpler and
shorter, but the reason I chose this GUC name is for consistency with
other autovacuum parameters. Existing autovacuum parameters that have
separate settings for vacuum and analyze operations follow the pattern
autovacuum_{vacuum|analyze}_*.
https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUMRight, but the GUCs that directly affect either vacuum or autovacuum
behaviour need the qualification (and then vacuum/analyze on top of it).
I think we have less constraints with the logging GUC and do not need to
mirror the behaviorial GUCs at all costs. But again, that is just my two
cents.I lean towards log_autovacuum_{vacuum|analyze}_min_duration. If
log_autovacuum_min_duration didn't exist, that's probably the naming scheme
we'd go with. However, I'm not sure we can get away with renaming
log_autovacuum_min_duration. Presumably we'd need to at least keep it
around as a backward-compatibility GUC, and its behavior would probably
change, too
I think deprecating a GUC like log_autovacuum_min_duration would be quite
difficult. May I suggest we keep its current behavior, which is to control
logging for both autoanalyze and autovacuum, and instead introduce only one
new GUC, log_autovacuum_analyze_min_duration, which defaults to -1? For
workloads that require different logging for autoanalyze, this new setting
can be enabled.
--
Sami Imseih
Amazon Web Services (AWS)
On 2025/06/04 4:32, Sami Imseih wrote:
On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote:
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
I surely think adding log_autoanalyze_min_duration is simpler and
shorter, but the reason I chose this GUC name is for consistency with
other autovacuum parameters. Existing autovacuum parameters that have
separate settings for vacuum and analyze operations follow the pattern
autovacuum_{vacuum|analyze}_*.
https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUMRight, but the GUCs that directly affect either vacuum or autovacuum
behaviour need the qualification (and then vacuum/analyze on top of it).
I think we have less constraints with the logging GUC and do not need to
mirror the behaviorial GUCs at all costs. But again, that is just my two
cents.I lean towards log_autovacuum_{vacuum|analyze}_min_duration. If
log_autovacuum_min_duration didn't exist, that's probably the naming scheme
we'd go with. However, I'm not sure we can get away with renaming
log_autovacuum_min_duration. Presumably we'd need to at least keep it
around as a backward-compatibility GUC, and its behavior would probably
change, tooI think deprecating a GUC like log_autovacuum_min_duration would be quite
difficult.
Also deprecating the log_autovacuum_min_duration reloption might be tricky.
If we remove support for it in v19, how should pg_dump handle tables with
this option set from older versions? Should it translate it into both
log_autovacuum_vacuum_min_duration and log_autovacuum_analyze_min_duration
during dump? Would pg_upgrade run into the same issue?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
HI
I vote log_autovacuum_{vacuum|analyze}_min_duration. Then don't remove
log_autovacuum_min_duration so easily!
On Wed, Jun 4, 2025 at 7:16 AM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:
Show quoted text
On 2025/06/04 4:32, Sami Imseih wrote:
On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote:
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
I surely think adding log_autoanalyze_min_duration is simpler and
shorter, but the reason I chose this GUC name is for consistency with
other autovacuum parameters. Existing autovacuum parameters that have
separate settings for vacuum and analyze operations follow the pattern
autovacuum_{vacuum|analyze}_*.https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUM
Right, but the GUCs that directly affect either vacuum or autovacuum
behaviour need the qualification (and then vacuum/analyze on top ofit).
I think we have less constraints with the logging GUC and do not need
to
mirror the behaviorial GUCs at all costs. But again, that is just my
two
cents.
I lean towards log_autovacuum_{vacuum|analyze}_min_duration. If
log_autovacuum_min_duration didn't exist, that's probably the namingscheme
we'd go with. However, I'm not sure we can get away with renaming
log_autovacuum_min_duration. Presumably we'd need to at least keep it
around as a backward-compatibility GUC, and its behavior would probably
change, tooI think deprecating a GUC like log_autovacuum_min_duration would be quite
difficult.Also deprecating the log_autovacuum_min_duration reloption might be tricky.
If we remove support for it in v19, how should pg_dump handle tables with
this option set from older versions? Should it translate it into both
log_autovacuum_vacuum_min_duration and log_autovacuum_analyze_min_duration
during dump? Would pg_upgrade run into the same issue?Regards,
--
Fujii Masao
NTT DATA Japan Corporation
Thank you all for the comments!
On Wed, Jun 4, 2025 at 10:30 AM wenhui qiu <qiuwenhuifx@gmail.com> wrote:
HI
I vote log_autovacuum_{vacuum|analyze}_min_duration. Then don't remove log_autovacuum_min_duration so easily!On Wed, Jun 4, 2025 at 7:16 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
On 2025/06/04 4:32, Sami Imseih wrote:
On Tue, Jun 03, 2025 at 10:57:11AM +0200, Michael Banck wrote:
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
I surely think adding log_autoanalyze_min_duration is simpler and
shorter, but the reason I chose this GUC name is for consistency with
other autovacuum parameters. Existing autovacuum parameters that have
separate settings for vacuum and analyze operations follow the pattern
autovacuum_{vacuum|analyze}_*.
https://www.postgresql.org/docs/devel/runtime-config-vacuum.html#RUNTIME-CONFIG-AUTOVACUUMRight, but the GUCs that directly affect either vacuum or autovacuum
behaviour need the qualification (and then vacuum/analyze on top of it).
I think we have less constraints with the logging GUC and do not need to
mirror the behaviorial GUCs at all costs. But again, that is just my two
cents.I lean towards log_autovacuum_{vacuum|analyze}_min_duration. If
log_autovacuum_min_duration didn't exist, that's probably the naming scheme
we'd go with. However, I'm not sure we can get away with renaming
log_autovacuum_min_duration. Presumably we'd need to at least keep it
around as a backward-compatibility GUC, and its behavior would probably
change, tooI think deprecating a GUC like log_autovacuum_min_duration would be quite
difficult.Also deprecating the log_autovacuum_min_duration reloption might be tricky.
If we remove support for it in v19, how should pg_dump handle tables with
this option set from older versions? Should it translate it into both
log_autovacuum_vacuum_min_duration and log_autovacuum_analyze_min_duration
during dump? Would pg_upgrade run into the same issue?
I understand it's hard to deprecate log_autovacuum_min_duration. I
think there are three approaches that reflect your comments.
Approach 1:
- log_autovacuum_min_duration: Same behavior, which controls
autovacuum and autoanalyze logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.
Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.
Approach 3:
- log_autovacuum_min_duration: Retained for backward compatibility.
- log_autovacuum_{vacuum,analyze}_min_duration: New parameter.
Thoughts?
And I added a new entry for the next commitfest.
https://commitfest.postgresql.org/patch/5797/
--
Best regards,
Shinya Kato
NTT OSS Center
Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.
My vote is for this approach. It is probably OK to change the behavior of
log_autovacuum_min_duration, as the new GUC will have the same default
value.
log_autoanalyze_min_duration makes sense, especially since
"autoanalyze" is the term we already use in system views (e.g.,
pg_stat_all_tables.last_autoanalyze). I do not think we need to worry
about consistency with other autovacuum parameters (e.g.,
autovacuum_[vacuum|analyze]_threshold, etc.), because in this case we are
only talking about logging, so we have more flexibility in naming.
Initially, I was not sure if there is a use case in which someone would want
to turn off autovacuum logging but keep autoanalyze logging (or vice versa),
but there may be, and this will be more flexible.
--
Sami Imseih
On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih <samimseih@gmail.com> wrote:
Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the behavior of
log_autovacuum_min_duration, as the new GUC will have the same default
value.
Thank you for voting. I also think this approach is reasonable to implement.
log_autoanalyze_min_duration makes sense, especially since
"autoanalyze" is the term we already use in system views (e.g.,
pg_stat_all_tables.last_autoanalyze). I do not think we need to worry
about consistency with other autovacuum parameters (e.g.,
autovacuum_[vacuum|analyze]_threshold, etc.), because in this case we are
only talking about logging, so we have more flexibility in naming.
+1.
Initially, I was not sure if there is a use case in which someone would
want
to turn off autovacuum logging but keep autoanalyze logging (or vice
versa),
but there may be, and this will be more flexible.
My concern is less about turning autovacuum and autoanalyze logs on or off
individually, and more about the fact that setting a large value for
log_autovacuum_min_duration prevents autoanalyze logs from being recorded.
--
Best regards,
Shinya Kato
NTT OSS Center
On Wed, Jun 11, 2025 at 1:49 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih <samimseih@gmail.com> wrote:
Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the behavior of
log_autovacuum_min_duration, as the new GUC will have the same default
value.Thank you for voting. I also think this approach is reasonable to
implement.
A new patch is attached.
Thoughts?
--
Best regards,
Shinya Kato
NTT OSS Center
Attachments:
v2-0001-Add-log_autoanalyze_min_duration.patchapplication/octet-stream; name=v2-0001-Add-log_autoanalyze_min_duration.patchDownload+128-32
On Mon, Jun 23, 2025 at 4:24 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
On Wed, Jun 11, 2025 at 1:49 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih <samimseih@gmail.com> wrote:
Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the behavior of
log_autovacuum_min_duration, as the new GUC will have the same default
value.Thank you for voting. I also think this approach is reasonable to implement.
A new patch is attached.
Thoughts?
Rebased.
--
Best regards,
Shinya Kato
NTT OSS Center
Attachments:
v3-0001-Add-log_autoanalyze_min_duration.patchapplication/octet-stream; name=v3-0001-Add-log_autoanalyze_min_duration.patchDownload+128-32
Hi,
2025-07-02 15:37 に Shinya Kato wrote:
On Mon, Jun 23, 2025 at 4:24 PM Shinya Kato <shinya11.kato@gmail.com>
wrote:On Wed, Jun 11, 2025 at 1:49 PM Shinya Kato <shinya11.kato@gmail.com>
wrote:On Thu, Jun 5, 2025 at 3:53 AM Sami Imseih <samimseih@gmail.com>
wrote:Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the
behavior of
log_autovacuum_min_duration, as the new GUC will have the same
default
value.Thank you for voting. I also think this approach is reasonable to
implement.A new patch is attached.
Thoughts?
I reviewed this patch.
I also have no particular objections to the Approach 2.
+ <term><literal>log_autoanalyze_min_duration</literal>,
<literal>toast.log_autoanalyze_min_duration</literal>(<type>integer</type>)
(snip)
+ "toast.log_autoanalyze_min_duration",
This patch adds the log_autoanalyze_min_duration parameter fot TOAST
tables.
However since PostgreSQL currently does not support ANALYZE on TOAST
tables,
isn't this parameter unnecessary?
Best regards,
--
Kasahara Tatsuhito
NTT DATA Japan Corporation
Hi,
On Wed, Aug 13, 2025 at 5:44 PM kasaharatt <kasaharatt@oss.nttdata.com> wrote:
Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the
behavior of
log_autovacuum_min_duration, as the new GUC will have the same
default
value.Thank you for voting. I also think this approach is reasonable to
implement.A new patch is attached.
Thoughts?I reviewed this patch.
I also have no particular objections to the Approach 2.
Thank you for the review!
+ <term><literal>log_autoanalyze_min_duration</literal>,
<literal>toast.log_autoanalyze_min_duration</literal>(<type>integer</type>)(snip)
+ "toast.log_autoanalyze_min_duration",
This patch adds the log_autoanalyze_min_duration parameter fot TOAST
tables.
However since PostgreSQL currently does not support ANALYZE on TOAST
tables,
isn't this parameter unnecessary?
You're right; that was a mistake. I've fixed it in the v4 patch.
+log_autoanalyze_min_duration = 0
Additionally, I removed the above setting from the test files in
src/test/modules/xid_wraparound/t/ (001_emergency_vacuum.pl,
002_limits.pl, 003_wraparounds.pl). The reason is that these tests
check for autovacuum logs, not autoanalyze logs. You can run the test
with the following command:
make check -C src/test/modules/xid_wraparound PG_TEST_EXTRA='xid_wraparound'
--
Best regards,
Shinya Kato
NTT OSS Center
Attachments:
v4-0001-Add-log_autoanalyze_min_duration.patchapplication/octet-stream; name=v4-0001-Add-log_autoanalyze_min_duration.patchDownload+124-32
Hi,
2025-08-14 13:26 に Shinya Kato wrote:
Hi,
On Wed, Aug 13, 2025 at 5:44 PM kasaharatt <kasaharatt@oss.nttdata.com>
wrote:Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the
behavior of
log_autovacuum_min_duration, as the new GUC will have the same
default
value.Thank you for voting. I also think this approach is reasonable to
implement.A new patch is attached.
Thoughts?I reviewed this patch.
I also have no particular objections to the Approach 2.Thank you for the review!
+ <term><literal>log_autoanalyze_min_duration</literal>,
<literal>toast.log_autoanalyze_min_duration</literal>(<type>integer</type>)(snip)
+ "toast.log_autoanalyze_min_duration",
This patch adds the log_autoanalyze_min_duration parameter fot TOAST
tables.
However since PostgreSQL currently does not support ANALYZE on TOAST
tables,
isn't this parameter unnecessary?You're right; that was a mistake. I've fixed it in the v4 patch.
Thanks for the patch updating.
Additionally, I removed the above setting from the test files in
src/test/modules/xid_wraparound/t/ (001_emergency_vacuum.pl,
002_limits.pl, 003_wraparounds.pl). The reason is that these tests
check for autovacuum logs, not autoanalyze logs. You can run the test
with the following command:
make check -C src/test/modules/xid_wraparound
PG_TEST_EXTRA='xid_wraparound'
Yeah, I agree that.
I confirmed this patch could apply to HEAD and all make check tests were
passed.
I've manually tested it in a few different ways, and it's working as
expected so far.
Unless there are any objections from others, I think I can mark this
patch as "Ready for Committer".
Best regards,
--
Kasahara Tatsuhito
NTT DATA Japan Corporation
2025-08-14 17:56 に kasaharatt wrote:
Hi,
2025-08-14 13:26 に Shinya Kato wrote:
Hi,
On Wed, Aug 13, 2025 at 5:44 PM kasaharatt
<kasaharatt@oss.nttdata.com> wrote:Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the
behavior of
log_autovacuum_min_duration, as the new GUC will have the same
default
value.Thank you for voting. I also think this approach is reasonable to
implement.A new patch is attached.
Thoughts?I reviewed this patch.
I also have no particular objections to the Approach 2.Thank you for the review!
+ <term><literal>log_autoanalyze_min_duration</literal>,
<literal>toast.log_autoanalyze_min_duration</literal>(<type>integer</type>)(snip)
+ "toast.log_autoanalyze_min_duration",
This patch adds the log_autoanalyze_min_duration parameter fot TOAST
tables.
However since PostgreSQL currently does not support ANALYZE on TOAST
tables,
isn't this parameter unnecessary?You're right; that was a mistake. I've fixed it in the v4 patch.
Thanks for the patch updating.
Additionally, I removed the above setting from the test files in
src/test/modules/xid_wraparound/t/ (001_emergency_vacuum.pl,
002_limits.pl, 003_wraparounds.pl). The reason is that these tests
check for autovacuum logs, not autoanalyze logs. You can run the test
with the following command:
make check -C src/test/modules/xid_wraparound
PG_TEST_EXTRA='xid_wraparound'Yeah, I agree that.
I confirmed this patch could apply to HEAD and all make check tests
were passed.
I've manually tested it in a few different ways, and it's working as
expected so far.Unless there are any objections from others, I think I can mark this
patch as "Ready for Committer".
Since there were no particular comments, I've marked it as Ready for
Committer.
Best regards,
--
Kasahara Tatsuhito
NTT DATA Japan Corporation
Hi,
2025-08-21 16:39 に kasaharatt wrote:
2025-08-14 17:56 に kasaharatt wrote:
Hi,
2025-08-14 13:26 に Shinya Kato wrote:
Hi,
On Wed, Aug 13, 2025 at 5:44 PM kasaharatt
<kasaharatt@oss.nttdata.com> wrote:Approach 2:
- log_autovacuum_min_duration: Changed behavior, which controls only
autovacuum logging.
- log_autoanalyze_min_duration: New parameter, which controls
autoanalyze logging.My vote is for this approach. It is probably OK to change the
behavior of
log_autovacuum_min_duration, as the new GUC will have the same
default
value.Thank you for voting. I also think this approach is reasonable to
implement.A new patch is attached.
Thoughts?I reviewed this patch.
I also have no particular objections to the Approach 2.Thank you for the review!
+ <term><literal>log_autoanalyze_min_duration</literal>,
<literal>toast.log_autoanalyze_min_duration</literal>(<type>integer</type>)(snip)
+ "toast.log_autoanalyze_min_duration",
This patch adds the log_autoanalyze_min_duration parameter fot TOAST
tables.
However since PostgreSQL currently does not support ANALYZE on TOAST
tables,
isn't this parameter unnecessary?You're right; that was a mistake. I've fixed it in the v4 patch.
Thanks for the patch updating.
Additionally, I removed the above setting from the test files in
src/test/modules/xid_wraparound/t/ (001_emergency_vacuum.pl,
002_limits.pl, 003_wraparounds.pl). The reason is that these tests
check for autovacuum logs, not autoanalyze logs. You can run the test
with the following command:
make check -C src/test/modules/xid_wraparound
PG_TEST_EXTRA='xid_wraparound'Yeah, I agree that.
I confirmed this patch could apply to HEAD and all make check tests
were passed.
I've manually tested it in a few different ways, and it's working as
expected so far.Unless there are any objections from others, I think I can mark this
patch as "Ready for Committer".Since there were no particular comments, I've marked it as Ready for
Committer.
The changes(*) to guc_tables.c have been pushed into HEAD,
so you may need to fix the patch.
Best regards,
--
Kasahara Tatsuhito
NTT DATA Japan Corporation
Hi,
On Thu, Sep 4, 2025 at 11:31 AM kasaharatt <kasaharatt@oss.nttdata.com> wrote:
The changes(*) to guc_tables.c have been pushed into HEAD,
so you may need to fix the patch.
Thank you for reporting and I fixed the patch.
--
Best regards,
Shinya Kato
NTT OSS Center
Attachments:
v5-0001-Add-log_autoanalyze_min_duration.patchapplication/octet-stream; name=v5-0001-Add-log_autoanalyze_min_duration.patchDownload+120-32
2025-09-04 13:13 に Shinya Kato wrote:
Hi,
On Thu, Sep 4, 2025 at 11:31 AM kasaharatt <kasaharatt@oss.nttdata.com>
wrote:The changes(*) to guc_tables.c have been pushed into HEAD,
so you may need to fix the patch.Thank you for reporting and I fixed the patch.
Thank you for the quick fix.
I've confirmed that it can be applied to HEAD and that all regression
tests pass.
I've run a few quick local checks and it works as expected.
ISTM there are no particular issues with the changes.
The status has been changed to Ready for Committer again.
Best regards,
--
Kasahara Tatsuhito
NTT DATA Japan Corporation
