Re: n_ins_since_vacuum stats for aborted transactions - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: n_ins_since_vacuum stats for aborted transactions
Date
Msg-id CAA5RZ0uZJBDman4q4+L6+tx-hQ40pziQbL=_+i9pN0g3nRXNEg@mail.gmail.com
Whole thread Raw
In response to Re: n_ins_since_vacuum stats for aborted transactions  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: n_ins_since_vacuum stats for aborted transactions
Re: n_ins_since_vacuum stats for aborted transactions
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Streaming relation data out of order
Next
From: Ilia Evdokimov
Date:
Subject: Re: explain analyze rows=%.0f