Re: Idea for getting rid of VACUUM FREEZE on cold pages
От | Simon Riggs |
---|---|
Тема | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Дата | |
Msg-id | 1276065484.12489.6336.camel@ebony обсуждение исходный текст |
Ответ на | Re: Idea for getting rid of VACUUM FREEZE on cold pages (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, 2010-06-08 at 18:35 -0400, Tom Lane wrote: > 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. No, it doesn't of itself, but if you raise a complaint then we must first address the complaint as a sub-topic before we continue the main discussion around $TOPIC. My proposal removes the barrier that early freezing would overwrite xmin values, so early freezing need not have any negative effects. The general idea is to hide the "third write" (freezing) on a tuple by making it happen at the same time as another tuple's "second write" (hint bit setting). I'm happy to let that continue by the OPs. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: