Re: Idea for getting rid of VACUUM FREEZE on cold pages
От | Tom Lane |
---|---|
Тема | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Дата | |
Msg-id | 9200.1275501931@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Idea for getting rid of VACUUM FREEZE on cold pages (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Idea for getting rid of VACUUM FREEZE on cold pages
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > The problem is that vacuum doesn't know that a certain part of the table > is already frozen. It needs to scan it completely anyways. If we had a > "frozen" map, we could mark pages that are completely frozen and thus do > not need any vacuuming; but we don't (I don't recall the reasons for > this. Maybe it's just that no one has gotten around to it, or maybe > there's something else). Offhand I think the reason is that you'd have to trust the frozen bit to be 100% correct (or at least never set to 1 in error). Currently, both the FSM and visibility forks are just hints, and we won't suffer data corruption if they're wrong; so we don't get too tense about WAL logging or fsync'ing updates. I believe Heikki is looking into what it'd take to make the visibility map 100% reliable, in connection with the desire for index-only scans. If we get that and the overhead isn't too terrible maybe we could build a frozen-status map the same way. regards, tom lane
В списке pgsql-hackers по дате отправления: