Re: Toast issues with OldestXmin going backwards - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Toast issues with OldestXmin going backwards
Date
Msg-id 878t9gcf9j.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Toast issues with OldestXmin going backwards  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

 Andrew> There is still some overhead in the check, of course; I will
 Andrew> see about doing some benchmarks.

Preliminary result suggests that the user-CPU cost of vacuum full
increases by ~16% when the entire table is recently-dead rows (with a
toasted column of ~10k length) compared to the same table when all rows
are live.

Since I doubt the practical value of vacuum full on a table which is
100% recently-dead, and that I would expect the live:recently-dead ratio
to not normally be much worse than 1:1 (making the overhead 8%) and more
likely up around 10:1 (making the overhead 1.5%), I think this is not an
issue. (When you have a lot of recently-dead rows is exactly the _wrong_
time to be doing a vacuum full, since it wouldn't save you any space and
you'd bloat the toast table as mentioned previously.)

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Toast issues with OldestXmin going backwards
Next
From: Peter Geoghegan
Date:
Subject: Re: Corrupted btree index on HEAD because of covering indexes