Re: document the need to analyze partitioned tables

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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-01-25 06:46:04
Message-ID: 216da165b47db064dcaa55b15b9b6cf470a088aa.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2023-01-25 at 16:26 +1300, David Rowley wrote:
> On Wed, 18 Jan 2023 at 22:15, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> > Attached is a new version of my patch that tries to improve the wording.
>
> I had a look at this and agree that we should adjust the paragraph in
> question if people are finding it confusing.
>
> I started to adjust that but since the text is fairly short it turned
> out quite different from what you had.
>
> I ended up with:
>
> +    With partitioned tables, since these do not directly store tuples, these
> +    do not require autovacuum to perform any <command>VACUUM</command>
> +    operations.  Autovacuum simply performs a <command>VACUUM</command> on the
> +    partitioned table's partitions the same as it does with normal tables.
> +    However, the same is true for <command>ANALYZE</command> operations, and
> +    this can be problematic as there are various places in the query planner
> +    that attempt to make use of table statistics for partitioned tables when
> +    partitioned tables are queried.  For now, you can work around this problem
> +    by running a manual <command>ANALYZE</command> command on the partitioned
> +    table when the partitioned table is first populated, and again whenever
> +    the distribution of data in its partitions changes significantly.
>
> which I've also attached in patch form.
>
> I know there's been a bit of debate on the wording and a few patches,
> so I may not be helping.  If nobody is against the above, then I don't
> mind going ahead with it and backpatching to whichever version this
> first applies to. I just felt I wasn't 100% happy with what was being
> proposed.

Thanks, your help is welcome.

Did you see Justin's wording suggestion in
https://postgr.es/m/20230118174919.GA9837%40telsasoft.com ?
He didn't attach it as a patch, so you may have missed it.
I was pretty happy with that.

I think your first sentence it a bit clumsy and might be streamlined to

Partitioned tables do not directly store tuples and consequently do not
require autovacuum to perform any <command>VACUUM</command> operations.

Also, I am a little bit unhappy about

1. Your paragraph states that partitioned table need no autovacuum,
but doesn't state unmistakably that they will never be treated
by autovacuum.

2. You make a distinction between table partitions and "normal tables",
but really there is no distiction.

Perhaps I am being needlessly picky here...

Yours,
Laurenz Albe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2023-01-25 06:51:26 RE: Perform streaming logical transactions by background workers and parallel apply
Previous Message Amit Kapila 2023-01-25 06:27:41 Re: Perform streaming logical transactions by background workers and parallel apply