On Wed, Apr 9, 2025 at 4:23 PM Mark Dilger <mark.dilger@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
toget 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
