Hello, > Besides the complexity of > getting that infrastructure in place, an important question is whether > the current system of applying threshold and scale factor to > changes_since_analyze should be used as-is for inheritance parents > (partitioned tables), because if users set those parameters similarly > to for regular tables, autovacuum might analyze partitioned tables > more than necessary. We'll either need a different formula, or some > commentary in the documentation about how partitioned tables might > need different setting, or maybe both. > I'm not sure but I think we need new autovacuum parameters for partitioned tables (autovacuum, autovacuum_analyze_threshold, autovacuum_analyze_scale_factor) because whether it's necessary to run autovacuum on partitioned tables will depend on users. What do you think?
> How are you going to track changes_since_analyze of partitioned table? > It's just an idea but we can accumulate changes_since_analyze of > partitioned table by adding child tables's value after analyzing each > child table. And compare the partitioned tables value to the threshold > that is computed by (autovacuum_analyze_threshold + total rows > including all child tables * autovacuum_analyze_scale_factor). > The idea Sawada-san mentioned is similar to mine. Also, for tracking changes_since_analyze, we have to make partitioned table's statistics. To do that, we can invent a new PgStat_StatPartitionedTabEntry based on PgStat_StatTabEntry. Through talking with Amit, I think the new structure needs the following members: tableid changes_since_analyze analyze_timestamp analyze_count autovac_analyze_timestamp autovac_analyze_count Vacuum doesn't run on partitioned tables, so I think members related to (auto) vacuum need not be contained in the structure. I'm still writing a patch. I'll send it this week. -- Best regards, Yuzuko Hosoya NTT Open Source Software Center