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

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

For your wording, I found I had a small problem with calling
partitions of a partitioned tables "normal tables" in:

+    The partitions of a partitioned table are normal tables and get processed
+    by autovacuum, but autovacuum doesn't process the partitioned table itself.

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.

David

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: GUCs to control abbreviated sort keys
Next
From: Andrew
Date:
Subject: Fix to enum hashing for dump and restore