Re: document the need to analyze partitioned tables

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, yuzuko <yuzukohosoya(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: document the need to analyze partitioned tables
Date: 2023-10-02 02:48:20
Message-ID: b44a25a7b28d6c47712564d62045e5f6312e52e2.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2023-09-29 at 22:34 -0400, Bruce Momjian wrote:
> Very good point! Updated patch attached.

Thanks! Some small corrections:

> diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
> index 9cf9d030a8..be1c522575 100644
> --- a/doc/src/sgml/maintenance.sgml
> +++ b/doc/src/sgml/maintenance.sgml
> @@ -861,10 +861,16 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
>     </para>
>  
>     <para>
> - Partitioned tables are not processed by autovacuum. Statistics
> - should be collected by running a manual <command>ANALYZE</command> when it is
> - first populated, and again whenever the distribution of data in its
> - partitions changes significantly.
> + Partitioned tables do not directly store tuples and consequently
> + autovacuum does not <command>VACUUM</command> them. (Autovacuum does

... does not <command>VACUUM</command> or <command>ANALYZE</command> them.

Perhaps it would be shorter to say "does not process them" like the
original wording.

> + perform <command>VACUUM</command> on table partitions just like other

Just like *on* other tables, right?

> + tables.) Unfortunately, this also means that autovacuum doesn't
> + run <command>ANALYZE</command> on partitioned tables, and this
> + can cause suboptimal plans for queries that reference partitioned
> + table statistics. You can work around this problem by manually
> + running <command>ANALYZE</command> on partitioned tables when they
> + are first populated, and again whenever the distribution of data in
> + their partitions changes significantly.
>     </para>
>  
>     <para>

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2023-10-02 03:20:50 Re: Document that server will start even if it's unable to open some TCP/IP ports
Previous Message Noah Misch 2023-10-02 01:31:26 Re: pgstatindex vs. !indisready