| From: | David Rowley <dgrowleyml(at)gmail(dot)com> | 
|---|---|
| To: | wenhui qiu <qiuwenhuifx(at)gmail(dot)com> | 
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: another autovacuum scheduling thread | 
| Date: | 2025-10-30 10:36:25 | 
| Message-ID: | CAApHDvohuOypudeuj7nVb9XCyg=u2JR2j00j4zYPGzBjn78piA@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Thu, 30 Oct 2025 at 19:48, wenhui qiu <qiuwenhuifx(at)gmail(dot)com> wrote:
>      I think there might be some misunderstanding — I’m only suggesting changing
> effective_xid_failsafe_age = Max(vacuum_failsafe_age,
>                                  autovacuum_freeze_max_age * 1.05);
> to
> effective_xid_failsafe_age = (vacuum_failsafe_age + autovacuum_freeze_max_age) / 2.0;
> In the current logic, effective_xid_failsafe_age is almost always equal to vacuum_failsafe_age.
> As a result, increasing the vacuum priority only when a table’s age reaches vacuum_failsafe_age is too late.
I understand your proposal. The autovacuum will trigger for the
wraparound at autovacuum_freeze_max_age, so for autovacuum still not
to have gotten to the table by the time the table is aged at
vacuum_failsafe_age, it means autovacuum isn't working quickly enough
to get through the workload, therefore the problem is with the speed
of autovacuum not the priority of autovacuum.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Filip Janus | 2025-10-30 10:39:38 | Re: Channel binding for post-quantum cryptography | 
| Previous Message | Peter Eisentraut | 2025-10-30 10:31:42 | Re: Fix incorrect const qualification for tbm_add_tuples() and itemptr_to_uint64() |