Re: Autovacuum on partitioned table (autoanalyze)
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: yuzuko <yuzukohosoya@gmail.com>, David Steele <david@pgmasters.net>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Daniel Gustafsson <daniel@yesql.se>, Amit Langote <amitlangote09@gmail.com>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Laurenz Albe <laurenz.albe@cybertec.at>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Greg Stark <stark@mit.edu>
Date: 2021-04-06T20:56:49Z
Lists: pgsql-hackers
On 2021-Apr-04, Tomas Vondra wrote: > 1) I still don't understand why inheritance and declarative partitioning > are treated differently. Seems unnecessary nad surprising, but maybe > there's a good reason? I think there is a good reason to treat them the same: pgstat does not have a provision to keep stats both of the table with children, and the table without children. It can only have one of those. For partitioning that doesn't matter: since the table-without-children doesn't have anything on its own (no scans, no tuples, no nothing) then we can just use the entry to store the table-with-children data. But for the inheritance case, the parent can have its own tuples and counts its own scans and so on; so if we change things, we'll overwrite the stats. Maybe in the long-term we should allow pgstat to differentiate those cases, but that seems not in scope for this patch. I'm working on the code to fix the other issues. -- Álvaro Herrera 39°49'30"S 73°17'W
Commits
-
Keep stats up to date for partitioned tables
- e1efc5b465c8 14.0 landed
- 375aed36ad83 15.0 landed
-
Revert analyze support for partitioned tables
- b3d24cc0f0aa 14.0 landed
- 6f8127b73901 15.0 landed
-
Document ANALYZE storage parameters for partitioned tables
- 41badeaba8be 14.0 landed
-
autovacuum: handle analyze for partitioned tables
- 0827e8af70f4 14.0 landed