| From: | Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> |
|---|---|
| To: | scott(at)scottray(dot)io |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Japin Li <japinli(at)hotmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Report oldest xmin source when autovacuum cannot remove tuples |
| Date: | 2026-05-31 13:06:36 |
| Message-ID: | CAOzEurTC+5xuH_X2EBWjW0Fs9iuTq3OMA=1FfT4xx1wYbCAR6g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, May 30, 2026 at 11:31 AM Scott Ray <scott(at)scottray(dot)io> wrote:
>
> > I guess the overhead of one more scan of the process array for every autovacuum
> > run if "log_autovacuum_min_duration" is non-zero (which is the default)
> > is acceptable.
>
>
> Could vacuum compute the blocker during ComputeXidHorizons and consume it at log time?
> Avoids the extra scan, and binds the blocker to the horizon vacuum used for pruning.
As Sami suggested in [0], I think this design is a cleaner approach
because it separates the responsibilities of ComputeXidHorizons and
the calculation of vacuum blockers.
--
Best regards,
Shinya Kato
NTT OSS Center
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Tatsuo Ishii | 2026-05-31 12:33:13 | Re: Row pattern recognition |