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

From Scott Ray
Subject Re: Report oldest xmin source when autovacuum cannot remove tuples
Date
Msg-id 3bnBUxwx2npXqvHL0trI11LOOvzQ7LI0GzWqbaj5SJnk7DTb1uzStGveKwj0JJmBW4ebzGIF3az7of4I4rQeaO_PRqDnnClCduPyjM6gPgM=@scottray.io
Whole thread
In response to autovacuum: automatically propagate updated parameters  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: Report oldest xmin source when autovacuum cannot remove tuples
List pgsql-hackers
> 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.

Scott Ray
Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: hashjoins vs. Bloom filters (yet again)
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition