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 | 11823.1276036500@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Idea for getting rid of VACUUM FREEZE on cold pages (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Idea for getting rid of VACUUM FREEZE on cold pages
Re: Idea for getting rid of VACUUM FREEZE on cold pages Re: Idea for getting rid of VACUUM FREEZE on cold pages Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote: >> OK, yes, I see what you're getting at now. There are two possible >> ways to do freeze the tuples and keep the xmin: we can either rely on >> the PD_ALL_VISIBLE page-level bit (as I previously proposed) or we can >> additionally have a HEAP_XMIN_FROZEN bit as you propose here. I am >> not sure which way is better. > Doing it at tuple level is more flexible and allows more aggressive > freezing. It also works better with existing tuple visibility code. I agree, relying on a page-level bit (or field) is unpleasant in a number of ways. But none of this accomplishes a damn thing towards the original goal, which was to avoid an extra disk write associated with freezing (not to mention an extra write for setting the transaction-committed hint bit). Setting a bit is no cheaper from that standpoint than changing the xmin field. regards, tom lane
В списке pgsql-hackers по дате отправления: