> One possible bad behaviour that this could cause is if
> autovacuum_vacuum_insert_scale_factor was set lower than
> autovacuum_vacuum_scale_factor is that we could end up performing a
> vacuum for inserts when all we've got is dead tuples from aborted
> inserts.
Thanks for pointing this out!
> We could fix it but it
> would require adding a new field to PgStat_TableCounts to track this
> as you can't selectively only update
> PgStat_TableCounts.tuples_inserted on commit as the n_tup_ins would
> then be wrong.
>
> If the above is the only misbehaviour this is causing, then I'm
> doubting that it's worth expanding PgStat_TableCounts by 8 bytes to
> have this work better.
I agree, as I mentioned at the top of the thread, rollbacks are
not common enough for this to be worth it. But, the code comment
as you have it is good enough.
> > So, I think public documentation updates to clarify that
> > n_tup_upd|del|ins, and n_ins_since_vacuum include
> > aborted rows is a good enhancement.
I also attached public doc clarification of how aborted ( and committed )
rows are handled for pg_stat_all_tables fields that count row changes
I initially thought
about adding clarification for every field, but that felt too
repetitive. So, I add a Note
section after pg_stat_all_tables in the public docs to describe the behavior.
It may be better to apply your code comment patch and the public
docs patch separately.
--
Sami Imseih
Amazon Web Services (AWS)
