Thread

Commits

  1. Remove autoanalyze corner case.

  1. remove autoanalyze corner case

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-04T02:55:25Z

    (new thread from [0])
    
    On Fri, Apr 03, 2026 at 02:13:16PM -0500, Sami Imseih wrote:
    >> * I noticed that if autovacuum decides to force a vacuum for
    >> anti-wraparound purposes, it might also decide to analyze the table even if
    >> autovacuum is disabled for it.  AFAICT this is accidental, but since it's
    >> behaved this way since commit 48188e1621 (2006) [0], I am slightly worried
    >> that this bug may have become a feature.  In 0002, I separated this edge
    >> case in the code and added a comment, and I intend to start a new thread
    >> about removing it.
    > 
    > hmm yeah, I think this just needs to be documented clearly. I always
    > thought it was expected for auto-analyze to run in this case, and I don't
    > see why it shouldn't. If this needs to be clarified in docs, we should
    > do that in a separate discussion.
    
    Well, autoanalyze only runs in this case if autovacuum is disabled via the
    table's autovacuum_enabled reloption and _not_ disabled via the autovacuum
    or track_counts GUCs.  I think this is pretty clearly unintentional, as I
    can find no mention in the code, archives, or docs.  And unless I'm missing
    something, it's completely unnecessary.  So IMHO we should just remove it.
    
    [0] https://postgr.es/m/CAA5RZ0sCRjH3xkHFdSXnKysdMZXFyaS_094%2BK-O_rr4Fkmwc%3DQ%40mail.gmail.com
    
    -- 
    nathan
    
  2. Re: remove autoanalyze corner case

    Robert Treat <rob@xzilla.net> — 2026-04-04T11:53:21Z

    On Fri, Apr 3, 2026 at 10:55 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
    >
    > (new thread from [0])
    >
    > On Fri, Apr 03, 2026 at 02:13:16PM -0500, Sami Imseih wrote:
    > >> * I noticed that if autovacuum decides to force a vacuum for
    > >> anti-wraparound purposes, it might also decide to analyze the table even if
    > >> autovacuum is disabled for it.  AFAICT this is accidental, but since it's
    > >> behaved this way since commit 48188e1621 (2006) [0], I am slightly worried
    > >> that this bug may have become a feature.  In 0002, I separated this edge
    > >> case in the code and added a comment, and I intend to start a new thread
    > >> about removing it.
    > >
    > > hmm yeah, I think this just needs to be documented clearly. I always
    > > thought it was expected for auto-analyze to run in this case, and I don't
    > > see why it shouldn't. If this needs to be clarified in docs, we should
    > > do that in a separate discussion.
    >
    > Well, autoanalyze only runs in this case if autovacuum is disabled via the
    > table's autovacuum_enabled reloption and _not_ disabled via the autovacuum
    > or track_counts GUCs.  I think this is pretty clearly unintentional, as I
    > can find no mention in the code, archives, or docs.  And unless I'm missing
    > something, it's completely unnecessary.  So IMHO we should just remove it.
    >
    > [0] https://postgr.es/m/CAA5RZ0sCRjH3xkHFdSXnKysdMZXFyaS_094%2BK-O_rr4Fkmwc%3DQ%40mail.gmail.com
    >
    
    AFAICS, near misses on wraparound in and of itself have no correlation
    with statistical changes in your data, so I'd agree it isn't
    necessary, and the fact that it behaves differently in this more
    narrow case than it would in the more general case, when these two
    cases are (as far as I've ever known) supposed to behave the same way,
    I'd be +1 to remove this.
    
    Robert Treat
    https://xzilla.net
    
    
    
    
  3. Re: remove autoanalyze corner case

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-04-04T12:40:51Z

    On 2026-Apr-04, Robert Treat wrote:
    
    > AFAICS, near misses on wraparound in and of itself have no correlation
    > with statistical changes in your data, so I'd agree it isn't
    > necessary, and the fact that it behaves differently in this more
    > narrow case than it would in the more general case, when these two
    > cases are (as far as I've ever known) supposed to behave the same way,
    > I'd be +1 to remove this.
    
    Yeah, that matches my impression.  +1 to remove it.
    
    -- 
    Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
    "La verdad no siempre es bonita, pero el hambre de ella sí"
    
    
    
    
  4. Re: remove autoanalyze corner case

    Sami Imseih <samimseih@gmail.com> — 2026-04-04T13:34:38Z

    >> AFAICS, near misses on wraparound in and of itself have no correlation
    >> with statistical changes in your data, so I'd agree it isn't
    >> necessary, and the fact that it behaves differently in this more
    >> narrow case than it would in the more general case, when these two
    >> cases are (as far as I've ever known) supposed to behave the same way,
    >> I'd be +1 to remove this.
    
    > Yeah, that matches my impression.  +1 to remove it.
    
    That is fine with me also.
    
    The patch LGTM.
    
    --
    Sami
    
    
    
    
  5. Re: remove autoanalyze corner case

    Shinya Kato <shinya11.kato@gmail.com> — 2026-04-05T13:46:08Z

    On Sat, Apr 4, 2026 at 11:55 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
    > Well, autoanalyze only runs in this case if autovacuum is disabled via the
    > table's autovacuum_enabled reloption and _not_ disabled via the autovacuum
    > or track_counts GUCs.  I think this is pretty clearly unintentional, as I
    > can find no mention in the code, archives, or docs.  And unless I'm missing
    > something, it's completely unnecessary.  So IMHO we should just remove it.
    
    +1. I think it might be better to mention this in the documentation to
    make the behavior explicit. What do you think about stating that an
    anti-wraparound autovacuum does not perform an ANALYZE, like in the
    attached patch?
    
    
    
    -- 
    Best regards,
    Shinya Kato
    NTT OSS Center
    
  6. Re: remove autoanalyze corner case

    Sami Imseih <samimseih@gmail.com> — 2026-04-05T22:28:06Z

    > > Well, autoanalyze only runs in this case if autovacuum is disabled via the
    > > table's autovacuum_enabled reloption and _not_ disabled via the autovacuum
    > > or track_counts GUCs.  I think this is pretty clearly unintentional, as I
    > > can find no mention in the code, archives, or docs.  And unless I'm missing
    > > something, it's completely unnecessary.  So IMHO we should just remove it.
    >
    > +1. I think it might be better to mention this in the documentation to
    > make the behavior explicit. What do you think about stating that an
    > anti-wraparound autovacuum does not perform an ANALYZE, like in the
    > attached patch?
    
    +1 to the additional documentation.
    
    a small nit: We can just say "skipped" and not "still skipped".
    
    --
    Sami
    
    
    
    
  7. Re: remove autoanalyze corner case

    Shinya Kato <shinya11.kato@gmail.com> — 2026-04-06T02:32:03Z

    On Mon, Apr 6, 2026 at 7:28 AM Sami Imseih <samimseih@gmail.com> wrote:
    > > +1. I think it might be better to mention this in the documentation to
    > > make the behavior explicit. What do you think about stating that an
    > > anti-wraparound autovacuum does not perform an ANALYZE, like in the
    > > attached patch?
    >
    > +1 to the additional documentation.
    >
    > a small nit: We can just say "skipped" and not "still skipped".
    
    Thanks, I've fixed it.
    
    -- 
    Best regards,
    Shinya Kato
    NTT OSS Center
    
  8. Re: remove autoanalyze corner case

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-06T16:29:41Z

    Committed.  I left out the documentation updates for now.
    
    -- 
    nathan
    
    
    
    
  9. Re: remove autoanalyze corner case

    Shinya Kato <shinya11.kato@gmail.com> — 2026-05-25T08:09:13Z

    On Tue, Apr 7, 2026 at 1:29 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
    >
    > Committed.  I left out the documentation updates for now.
    
    Thanks for committing! I've attached a patch with just the
    documentation updates, in case it's still useful.
    
    
    -- 
    Best regards,
    Shinya Kato
    NTT OSS Center