Re: n_ins_since_vacuum stats for aborted transactions
От | Andres Freund |
---|---|
Тема | Re: n_ins_since_vacuum stats for aborted transactions |
Дата | |
Msg-id | y6bmnws6saarasso5soqjna44lbygeyc7lejrfkbluttgxnyen@u6vmpcywtnmc обсуждение исходный текст |
Ответ на | Re: n_ins_since_vacuum stats for aborted transactions (Sami Imseih <samimseih@gmail.com>) |
Список | pgsql-hackers |
Hi, On 2025-04-09 17:05:39 -0500, Sami Imseih wrote: > On Wed, Apr 9, 2025 at 4:23 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > >> > >> 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? > > Vacuum works based on different thresholds already, right? A user is > able to configure different thresholds: > autovacuum_vacuum_scale_factor|threshold > autovacuum_vacuum_insert_scale_factor|threshold > > > What is the use case for that behavior? Perhaps you have one, but until you make it explicit, it is hard for othersto get behind your proposal. > > The point is to ensure that the pg_stats fields that autovacuum uses > are supplied the correct values > for the different thresholds they need to calculate, as described here [0] You so far have not outlined a single scenario where the current behaviour causes an issue. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: