Re: n_ins_since_vacuum stats for aborted transactions
От | Sami Imseih |
---|---|
Тема | Re: n_ins_since_vacuum stats for aborted transactions |
Дата | |
Msg-id | CAA5RZ0usiQ5X7cHU2b+8MsXmZxukBRPxiQqwNzA2kz2JkzFXwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: n_ins_since_vacuum stats for aborted transactions ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: n_ins_since_vacuum stats for aborted transactions
|
Список | pgsql-hackers |
> Except there isn’t some singular provably correct value here. Today’s behavior (considering dead tuples) > is not intrinsically wrong nor correct, and neither is what you propose (ignoring the dead tuples). > The fact that those dead tuples get removed regardless is a point in favor of counting them when deciding what to do. > And it’s also the long-standing behavior. You need to make a compelling argument to change to your preference. > > Inserting aborted dead tuples moves the counter closer to both autovacuum thresholds. > There is no reason why that should be prohibited. I can see the argument for why one > threshold should be dead tuples only and the other live tuples only - but I don’t favor that design. Fair enough, and I think I got my answers from this thread. This design decision was not discussed in the thread for b07642dbcd8. 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. Also a code comment in pgstat_relation_flush_cb that explains ins_since_vacuum intentionally includes aborted inserts. tabentry->ins_since_vacuum += lstats->counts.tuples_inserted; -- Sami Imseih
В списке pgsql-hackers по дате отправления: