Re: Idea for getting rid of VACUUM FREEZE on cold pages
От | Robert Haas |
---|---|
Тема | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Дата | |
Msg-id | AANLkTikMyZaw4wrfb9C3oBnFjJ0jOHhQhtOqg8JU7xP-@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Idea for getting rid of VACUUM FREEZE on cold pages (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Idea for getting rid of VACUUM FREEZE on cold pages
|
Список | pgsql-hackers |
On Tue, Jun 8, 2010 at 6:35 PM, Tom Lane <tgl@sss.pgh.pa.us> 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. Except for insert-only tables, I don't believe this is true. If you freeze all tuples by the time the pages are marked all-visible, perhaps via the xmin-preserving mechanism Simon suggested, then you can use the visibility map to skip anti-wraparound vacuum as well as regular vacuum. That sounds to me like it's accomplishing something. Is it a complete solution? No. Is it better than what we have now? Yes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: