Re: document the need to analyze partitioned tables

Laurenz Albe <laurenz.albe@cybertec.at>

From: Laurenz Albe <laurenz.albe@cybertec.at>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Justin Pryzby <pryzby@telsasoft.com>, Nathan Bossart <nathandbossart@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Álvaro Herrera <alvherre@alvh.no-ip.org>, yuzuko <yuzukohosoya@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-01-25T06:46:04Z
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.albe@cybertec.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



Commits

  1. doc: Fix typo in ANALYZE documentation

  2. Document autoanalyze limitations for partitioned tables

  3. Revert analyze support for partitioned tables

  4. Describe (auto-)analyze behavior for partitioned tables