Re: n_ins_since_vacuum stats for aborted transactions

Hi,

On 2025-04-09 17:05:39 -0500, Sami Imseih wrote:
> On Wed, Apr 9, 2025 at 4:23 PM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)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