On Wed, Apr 9, 2025 at 4:23 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: >> >> In other words, the reason n_ins_since_vacuum was introduced is to freeze >> (committed) rows, so it should not need to track dead rows to do what it >> intends >> to do. > > > Wouldn't that result in the rather strange behavior that 1 million dead rows > might trigger a vacuum due to one threshold, > 1 million inserted live rows might trigger a vacuum due to another threshold, > while half a million dead plus half a million live fails to meet either > threshold and fails to trigger a vacuum?
Vacuum works based on different thresholds already, right? A user is able to configure different thresholds: autovacuum_vacuum_scale_factor|threshold autovacuum_vacuum_insert_scale_factor|threshold > What is the use case for that behavior? Perhaps you have one, but until you > make it explicit, it is hard for others to get behind your proposal. The point is to ensure that the pg_stats fields that autovacuum uses are supplied the correct values for the different thresholds they need to calculate, as described here [0] [0] https://www.postgresql.org/message-id/CAA5RZ0uDyGW1omWqWkxyW8NB1qzsKmXhnoMtzTBeRzSd4DMatQ%40mail.gmail.com -- Sami Imseih
