>> >> 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


Reply via email to