Re: document the need to analyze partitioned tables - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: document the need to analyze partitioned tables
Date
Msg-id 216da165b47db064dcaa55b15b9b6cf470a088aa.camel@cybertec.at
Whole thread Raw
In response to Re: document the need to analyze partitioned tables  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: document the need to analyze partitioned tables
List 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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Perform streaming logical transactions by background workers and parallel apply