Thank you all for the comments!
On Wed, Jun 4, 2025 at 10:30 AM wenhui qiu <qiuwenhu...@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.fu...@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
