On Thu, 10 Apr 2025 at 10:54, Sami Imseih <samims...@gmail.com> wrote: > Fair enough, and I think I got my answers from this thread. This > design decision was not > discussed in the thread for b07642dbcd8.
This discussion is mostly settled down now, but... I also went through that thread to see if it was mentioned and saw nothing about it. 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. That does not seem terrible. It's just an extra autovacuum that could happen in a not very common case. 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. > 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. A code comment might help settle future debates. If you'd arrived from a user perspective and were confused about this, then maybe that would warrant something going into the docs. On the other hand, if you have a suggestion, please put it into patch form. I've attached a small patch which adds a code comment about this, which might save a future discussion. David
comments_about_using_tuples_inserted_for_ins_since_vacuum.patch
Description: Binary data
