You cannot tune what you cannot measure. Before adjusting any autovacuum parameter, you need to establish a baseline and identify which tables are actually suffering.
PostgreSQL: Key Diagnostic Queries
Start with pg_stat_all_tables, ranking tables by dead-tuple count and computing each one's dead-tuple percentage alongside its last_autovacuum/last_autoanalyze timestamps and how many times autovacuum has run on it — any table above 10–20% dead with a stale last_autovacuum is a candidate for per-table tuning. To see whether autovacuum is currently running and on what, filter pg_stat_activity for queries matching autovacuum:% and check how long each has been running. For real-time progress on an in-flight vacuum, pg_stat_progress_vacuum reports which phase it's in and how many heap blocks have been scanned versus vacuumed. And for an exact physical bloat estimate rather than an approximation, the pgstattuple extension's pgstattuple('tablename') function reports the dead-tuple byte count and percentage directly from the table's pages.
Cassandra: Key Diagnostic Commands
nodetool compactionstats reports pending compaction tasks cluster-wide, and nodetool tablestats <keyspace>.<table> reports SSTable count and size for a specific table. A high Pending Tasks count in compactionstats means compaction is falling behind. A very high SSTable count per table (hundreds or thousands) indicates that compaction is not keeping up with flushes, which will degrade read performance.
The combination of monitoring queries and per-table tuning is the complete workflow: measure first, identify the bottleneck (trigger threshold vs. speed vs. wrong strategy), then apply the targeted fix.