Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add log_autoanalyze_min_duration

  2. Generate GUC tables from .dat file

  1. Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-06-03T06:35:20Z

    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

  2. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Michael Banck <mbanck@gmx.net> — 2025-06-03T07:42:35Z

    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

  3. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-06-03T08:25:40Z

    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

  4. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Michael Banck <mbanck@gmx.net> — 2025-06-03T08:57:11Z

    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

  5. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Nathan Bossart <nathandbossart@gmail.com> — 2025-06-03T18:47:11Z

    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 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

  6. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Sami Imseih <samimseih@gmail.com> — 2025-06-03T19:32:02Z

    > 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 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)

  7. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Fujii Masao <masao.fujii@oss.nttdata.com> — 2025-06-03T23:15:56Z

    
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 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.

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

  8. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    wenhui qiu <qiuwenhuifx@gmail.com> — 2025-06-04T01:30:25Z

    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-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.
> >>
> >> 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.
>
> 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
>
>
>
>

  9. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-06-04T08:13:34Z

    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-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.
>> >>
>> >> 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.
>>
>> 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

  10. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Sami Imseih <samimseih@gmail.com> — 2025-06-04T18:53:27Z

    > 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

  11. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-06-11T04:49:39Z

    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

  12. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-06-23T07:24:53Z

    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

  13. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-07-02T06:37:49Z

    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

  14. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    kasaharatt <kasaharatt@oss.nttdata.com> — 2025-08-13T08:44:06Z

    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

  15. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-08-14T04:26:17Z

    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

  16. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    kasaharatt <kasaharatt@oss.nttdata.com> — 2025-08-14T08:56:40Z

    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

  17. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    kasaharatt <kasaharatt@oss.nttdata.com> — 2025-08-21T07:39:16Z

    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

  18. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    kasaharatt <kasaharatt@oss.nttdata.com> — 2025-09-04T02:31:43Z

    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.

(*) 
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=63599896545c7869f7dd28cd593e8b548983d613

Best regards,
-- 
Kasahara Tatsuhito
NTT DATA Japan Corporation

  19. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-09-04T04:13:09Z

    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.
>
> (*)
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=63599896545c7869f7dd28cd593e8b548983d613

Thank you for reporting and I fixed the patch.

-- 
Best regards,
Shinya Kato
NTT OSS Center

  20. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    kasaharatt <kasaharatt@oss.nttdata.com> — 2025-09-04T06:16:33Z

    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.
>> 
>> (*)
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=63599896545c7869f7dd28cd593e8b548983d613
> 
> 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

  21. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Peter Eisentraut <peter@eisentraut.org> — 2025-10-15T12:37:06Z

    On 04.09.25 08:16, kasaharatt wrote:
> 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.
>>>
>>> (*)
>>> https://git.postgresql.org/gitweb/? 
>>> p=postgresql.git;a=commit;h=63599896545c7869f7dd28cd593e8b548983d613
>>
>> 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.

Committed, thanks.

  22. Re: Add log_autovacuum_{vacuum|analyze}_min_duration

    Shinya Kato <shinya11.kato@gmail.com> — 2025-10-15T12:55:57Z

    On Wed, Oct 15, 2025 at 9:37 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 04.09.25 08:16, kasaharatt wrote:
> > 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.
> >>>
> >>> (*)
> >>> https://git.postgresql.org/gitweb/?
> >>> p=postgresql.git;a=commit;h=63599896545c7869f7dd28cd593e8b548983d613
> >>
> >> 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.
>
> Committed, thanks.

Thank you for pushing!


-- 
Best regards,
Shinya Kato
NTT OSS Center