| From: | VASUKI M <vasukianand0119(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Optional skipping of unchanged relations during ANALYZE? |
| Date: | 2026-01-21 06:43:55 |
| Message-ID: | CAE2r8H6b5UTn_0Fkd3fRpN3QwVogxEJKXrDy3uBm_YfQPCiTsw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi David,
Thanks for calling this out — yes, I agree this is an important case.
Partitioned tables are already something I’m considering separately, since
the parent’s n_mod_since_analyze does not reflect changes made in the
partitions. The intention is not to skip analysis of partitions just because
the partitioned parent itself shows no modifications.
For now, my approach is deliberately limited to using the statistics that
are
already available via pg_stat and making skip decisions only where those
statistics are meaningful and reliable.
That also means that for the initial version, I’m not trying to introduce
special handling for cases like foreign tables or system catalogs beyond
what
existing statistics already provide. Where statistics are missing, unclear,
or potentially misleading, the conservative behavior would be to fall back
to running ANALYZE as usual.
Thanks again for the feedback.
Regards,
Vasuki M
C-DAC,Chennai.
On Wed, Jan 21, 2026 at 12:06 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Wed, 21 Jan 2026 at 00:02, VASUKI M <vasukianand0119(at)gmail(dot)com> wrote:
> > On Tue, Jan 20, 2026 at 4:16 PM Christoph Berg <myon(at)debian(dot)org> wrote:
> >> Make sure that doesn't skip tables that were never analyzed before.
> >
> > Yes, the intention is that SMART ANALYZE would not skip relations that
> have never been analyzed before.
> > The skip decision is based on pg_stat entries, so relations without
> existing statistics will still be analyzed normally.
>
> If doing this, you would also need to make special consideration for
> partitioned tables, as n_mod_since_analyze won't change for those
> directly, but it might have changed for their partitions.
>
> David
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2026-01-21 07:10:46 | RE: Assert the timestamp is available for ORIGN_DIFFERS conflicts |
| Previous Message | John Naylor | 2026-01-21 06:40:11 | Re: tuple radix sort |