Re: Optional skipping of unchanged relations during ANALYZE?

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: VASUKI M <vasukianand0119(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>
Subject: Re: Optional skipping of unchanged relations during ANALYZE?
Date: 2026-01-30 05:28:03
Message-ID: CADkLM=eFRiQs6hZoPa+NrL8zUBjUF=BoSsLZOV-xG+LaRuL+5Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
> > But before we get there, we have to contend with the fact that what
> constitutes "missing" has already
> > subtly changed since v18, that change is not yet reflected in vacuumdb,
> and ideally the definition
> > would change back to the v18 definition before v19 feature freeze, but
> that isn't guaranteed.
>
> OK, I am confused a bit about the details of this point, but it looks
> like this work is happening
> in another thread, maybe [0] ?
>

Yes, but that thread was about to close and it was in the process of being
moved to [1] as I was writing that message. The only thing to keep in mind
is that if the effort in [1] stalls, then the definition of missing in
vacuumdb will likely get marginally more complex. I hope that doesn't
happen, and I believe that it won't, but I don't want anybody blind-sided
if it does.

So with regards to this thread, vacuumdb using this new option will be
> out of scope. This could
> be handled in a future thread.
>

+1

[1]
https://www.postgresql.org/message-id/flat/CADkLM%3DfPcci6oPyuyEZ0F4bWqAA7HzaWO%2BZPptufuX5_uWt6kw%40mail.gmail.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-01-30 05:30:44 Re: Document NULL
Previous Message shveta malik 2026-01-30 05:25:41 Re: pg_upgrade: optimize replication slot caught-up check