From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "Zechman, Derek S" <Derek(dot)S(dot)Zechman(at)snapon(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: analyze-in-stages post upgrade questions |
Date: | 2025-08-06 14:25:53 |
Message-ID: | CAHGQGwEj8PCk1OVveJ_F1sj_COrV95N-mfu_tLUn4gdcAM24kA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Wed, Aug 6, 2025 at 1:01 PM Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com> wrote:
> Overall, I like the change. But I have one question: should this be treated as
> a bug fix that we back-patch to supported branches, or is it more of
> an improvement that should only go into master?
>
> I reckon it might make sense to back-patch it to previous versions, as users might not upgrade always to the latest version.
I understand your point. But on second thought, since the patch changes
behavior, I'm leaning toward treating it as an improvement, so it should
only go to master...
> + /*
> + * VACUUMing partitioned tables would be unreasonably expensive, since
> + * that entails processing the partitions twice (once as part of the
> + * partitioned table, once as tables in their own right) for no
> + * benefit. But if we only ANALYZE, collecting statistics for
> + * partitioned tables is worth the effort.
> + */
>
> This is probably true. But isn't the main reason more about aligning with
> the behavior of the underlying VACUUM and ANALYZE commands? As the vacuumdb
> docs says, "There is no effective difference between vacuuming and analyzing
> databases via this utility and via other methods for accessing the server.",
> so its default target objects should match: VACUUM skips partitioned tables
> by default, while ANALYZE includes them. If that's the case, maybe the comment
> should reflect that instead.
>
> I see what you mean. From that perspective, I wonder if we even need a comment there at all.
Or, if we keep it, though, I'd like to update it to something like
the following:
--------------------
vacuumdb should generally follow the behavior of the underlying
VACUUM and ANALYZE commands. If analyze_only is true, process
regular tables, materialized views, and partitioned tables, just like
ANALYZE (with no specific target tables) does. Otherwise, process
only regular tables and materialized views, since VACUUM skips
partitioned tables when no target tables are specified.
--------------------
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2025-08-06 17:46:39 | Re: Libpq.dll |
Previous Message | Marco Torres | 2025-08-06 13:54:33 | Re: Stored procedures or raw queries |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2025-08-06 14:36:24 | Re: index prefetching |
Previous Message | Álvaro Herrera | 2025-08-06 14:20:24 | Re: SIMD optimization for list_sort |