On Thu, 10 Apr 2025 at 10:54, Sami Imseih <samimseih@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
