On Thu, Jan 12, 2023 at 03:27:47PM -0800, Nathan Bossart wrote: > On Wed, Oct 05, 2022 at 10:37:01AM +0200, Laurenz Albe wrote: > > On Mon, 2022-03-28 at 15:05 +0200, Tomas Vondra wrote: > >> I've pushed the last version, and backpatched it to 10 (not sure I'd > >> call it a bugfix, but I certainly agree with Justin it's worth > >> mentioning in the docs, even on older branches). > > > > I'd like to suggest an improvement to this. The current wording could > > be read to mean that dead tuples won't get cleaned up in partitioned tables. > > Well, dead tuples won't get cleaned up in partitioned tables, as > partitioned tables do not have storage. But I see what you mean. Readers > might misinterpret this to mean that autovacuum will not process the > partitions. There's a good definition of what the docs mean by > "partitioned table" [0], but FWIW it took me some time before I > consistently read "partitioned table" to mean "only the thing with relkind > set to 'p'" and not "both the partitioned table and its partitions." So, > while the current wording it technically correct, I think it'd be > reasonable to expand it to help avoid confusion. > > Here is my take on the wording: > > Since all the data for a partitioned table is stored in its partitions, > autovacuum does not process partitioned tables. Instead, autovacuum > processes the individual partitions that are regular tables. This > means that autovacuum only gathers statistics for the regular tables > that serve as partitions and not for the partitioned tables. Since > queries may rely on a partitioned table's statistics, you should > collect statistics via the ANALYZE command when it is first populated, > and again whenever the distribution of data in its partitions changes > significantly.
Uh, what about autovacuum's handling of partitioned tables? This makes it sound like it ignores them because it talks about manual ANALYZE. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Embrace your flaws. They make you human, rather than perfect, which you will never be.