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

From Mark Dilger
Subject Re: n_ins_since_vacuum stats for aborted transactions
Date
Msg-id CAHgHdKt1Wvr+DNp=5QBFMesfo+z2s-MLERTfDj0HcfkbSubjoA@mail.gmail.com
Whole thread Raw
In response to Re: n_ins_since_vacuum stats for aborted transactions  (Sami Imseih <samimseih@gmail.com>)
Responses Re: n_ins_since_vacuum stats for aborted transactions
List pgsql-hackers
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.

Wouldn't that result in the rather strange behavior that 1 million dead rows might trigger a vacuum due to one threshold, 1 million inserted live rows might trigger a vacuum due to another threshold, while half a million dead plus half a million live fails to meet either threshold and fails to trigger a vacuum?  What is the use case for that behavior?  Perhaps you have one, but until you make it explicit, it is hard for others to get behind your proposal.


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SQLFunctionCache and generic plans
Next
From: Matthias van de Meent
Date:
Subject: Summarizing indexes allowing single-phase VACUUM?