Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm worried about keeping RecentGlobalXmin up to date during the
>> vacuums, not only at the end, because it will be used for HOT page
>> pruning during the vacuums.
> Oh, I see. I didn't know we were doing HOT pruning during vacuum; does
> it make sense?
Sorry, I got a bit confused there. The vacuum's intentional pruning
will use its own OldestXmin variable, which is known current at the
start of the vacuum (and I think there were even proposals to advance
it more frequently than that). However, a vacuum could require some
incidental system catalog fetches, which I think could result in
prune operations based on RecentGlobalXmin on the catalog pages
(cf index_getnext).
So it's probably not too terribly important ... as long as an autovac
worker doesn't live long enough that its RecentGlobalXmin threatens
to wrap around ... but I'm still interested in it as a code cleanup
measure. Skipping the transaction snapshot fetch was a performance
kluge, and if we don't need it any more I'd like to get rid of that
distinction between full and lazy vacuum behavior.
Anyway I think we are on the same page about the rest of the issues.
Did you want to work on fixing them, or shall I?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
