vsbace commented on issue #1850: URL: https://github.com/apache/cloudberry/issues/1850#issuecomment-4968348675
I found a good document about vcauum in Greenplum 7 https://blogs.vmware.com/tanzu/autovacuum-tuning-in-gpdb7/ And i see some warrings about using autovacuum on all tables including AOT tables. "GPDB7 Autovacuum for Catalog Tables The autovacuum’s purpose is to automate VACUUM and ANALYZE executions. In previous versions of GPDB, autovacuum is only enabled in template1 to prevent xid wraparound. It is disabled for user tables due to performance issues (more on this later). Vacuum in gpdb is not a distributed function. Autovacuum is triggered locally on segments and each segment is unaware of other segment’s vacuum status. GPDB7 only enables auto vacuum on catalog tables. The reason for this is that the catalog tables are evenly distributed and individual updates are small. There’s no potential data skew that could result in one segment vacuum process taking much longer and blocking transactions for the whole cluster. Each individual segment’s catalog table can be updated without causing cluster-wide stalling. On a distributed system, enabling autovacuum for user tables is tricky. Distributed transactions can be stalled by autovacuum running on a user table on a single segment. This means that autovacuuming a user table on a single segment can stall the operations for all of GPBD. This is likely further exacerbated with increasing amount of segments. The experiments of enabling autovacuum in user tables showed an unacceptable level of performance degradation due to desynchronized autovacuums. The autovacuums on different segments would take turns stalling the cluster. This resulted in a laggy or jittery cluster. For this reason, autovacuum on user tables is not enabled in GPDB. Why not synchronize the autovacuums? This would theoretically prevent major performance regressions in a system where the all tables have similar skew and activity, but what about in other situations? There may would be other potential issues that may be introduced such as keeping the code aligned with upstream Postgres, complexity, or issues with corner cases. We will want to understand and be more certain of the benefits and ramifactions of making vacuum distributed." -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
