Re: Toast issues with OldestXmin going backwards
От | Andrew Gierth |
---|---|
Тема | Re: Toast issues with OldestXmin going backwards |
Дата | |
Msg-id | 878t9gcf9j.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Toast issues with OldestXmin going backwards (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | 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 по дате отправления: