Re: Report oldest xmin source when autovacuum cannot remove tuples - Mailing list pgsql-hackers

From Shinya Kato
Subject Re: Report oldest xmin source when autovacuum cannot remove tuples
Date
Msg-id CAOzEurTC+5xuH_X2EBWjW0Fs9iuTq3OMA=1FfT4xx1wYbCAR6g@mail.gmail.com
Whole thread
In response to Re: Report oldest xmin source when autovacuum cannot remove tuples  (Scott Ray <scott@scottray.io>)
List pgsql-hackers
On Sat, May 30, 2026 at 11:31 AM Scott Ray <scott@scottray.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.

[0] https://www.postgresql.org/message-id/CAA5RZ0s%2BUUXekbeGcC-H71kW%3DMfeaUCOV%3DyEWX94NXViO2-%3DpA%40mail.gmail.com


--
Best regards,
Shinya Kato
NTT OSS Center



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition
Next
From: "Joel Jacobson"
Date:
Subject: Re: Key joins