>> What I am saying is n_ins_since_vacuum should not account for aborted inserts. > > It does and from what I can see it should. You need to explain why it should not. More importantly, convincingly enough to change five year old behavior.
n_ins_since_vacuum was introduced to trigger autovacuum based on the # of inserts committed, and does not care about about dead tuples in this formula.
If I have a transaction that rolledback an insert of a million rows, I expect autovacuum to kick in based on the fact there are now 1 million n_dead_tup. n_ins_since_vacuumm is not relevant to the formula for this case.
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.
Well, then the authors failed to implement what they intended. Which seems unlikely, but even accepting that to be true, you still haven't shown that the current behavior is undesirable. Just unexpected. Which means we haven't documented this well enough so people reading the docs/code get an expectation that matches reality.
So, please, go ahead with some documentation/code comment changes. But, for my part, the existing behavior seems quite reasonable: "yes, please, get rid of my bloat on this otherwise infrequently updated table"; thus leave the existing behavior and the tracking alone.
