Hi, On 2025-04-09 17:05:39 -0500, Sami Imseih wrote: > 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]
You so far have not outlined a single scenario where the current behaviour causes an issue. Greetings, Andres Freund
