>> >> 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,
At least, the reasoning behind this is neither explained in code comments or in public docs. > you still haven't shown that the current behavior is undesirable. Just > unexpected. It's not expected for sure. As far as being undesirable, I don't think it is because rollbacks are not that common and this is not preventing or delaying autovacuum. I do think it's probably a good idea to add code comment that it is OK to include dead tuples from a aborted insert into the n_ins_since_vacuum counter, for the above reasons. I will also update the public documentation for the counters to mention that they include rows from aborted transactions. -- Sami Imseih