> 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)
0001-Clarify-when-aborted-and-committed-rows-are-tracked-.patch
Description: Binary data
