Re: n_ins_since_vacuum stats for aborted transactions
От | Sami Imseih |
---|---|
Тема | Re: n_ins_since_vacuum stats for aborted transactions |
Дата | |
Msg-id | CAA5RZ0uZJBDman4q4+L6+tx-hQ40pziQbL=_+i9pN0g3nRXNEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: n_ins_since_vacuum stats for aborted transactions (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: n_ins_since_vacuum stats for aborted transactions
Re: n_ins_since_vacuum stats for aborted transactions |
Список | pgsql-hackers |
> If we went with your suggestion, I think the final n_ins_since_vacuum column would be 2. Do you think the n_tup_ins shouldalso be 2? n_ins_since_vacuum should be 2 and n_tup_ins should be 100000. A user tracks how many inserts they performed with n_tup_ins to measure load/activity on the database. It's important to also include aborted transactions in this metric, n_ins_since_vacuum however is not used to measure database activity, but is used to drive autovacuum decisions. So, it has a different purpose. > Should those two columns differ? If so, why? They will differ because n_tup_ins keeps increasing, while n_ins_since_vacuum is reset after a vacuum. The issue I see is that n_ins_since_vacuum should only reflect the number of newly inserted rows that are eligible for freezing, as described in pgstat_report_vacuum [0] [0] https://github.com/postgres/postgres/blob/master/src/backend/utils/activity/pgstat_relation.c#L238-L247 -- Sami Imseih Amazon Web Services (AWS)
В списке pgsql-hackers по дате отправления: