> actually determine you are in this situation, or how bad the situation > was, in order to know that setting truncate off would help? To that
Adding counters for this area is not a bad idea in general, as this hits customers particularly hard on hot standbys when the truncate does actually occur on the primary. What about adding cumulative counters ( per table and pg_stat_database ) such as: pages_vac_truncated - # of pages truncated by vacuum vac_truncate_conflicts - # of time truncate was skipped due to conflict vac_truncate_suspended - # of times the truncate was suspended. The difference between conflict and suspended is conflict causes vacuum to skip the truncate phase while suspended causes vacuum to retry the phase continually. The argument against adding these counters is that the views, pg_stat_all_tables/ pg_stat_all_database are becoming super-wide, so maybe we need to think about inventing a new view for vacuum related counter metrics. This seems like a good discussion for v19. -- Sami
