Re: Visibility map thoughts
От | Heikki Linnakangas |
---|---|
Тема | Re: Visibility map thoughts |
Дата | |
Msg-id | 472F9D0D.4050106@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Visibility map thoughts (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Visibility map thoughts
("Marko Kreen" <markokr@gmail.com>)
Re: Visibility map thoughts (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
Jeff Davis wrote: > On Mon, 2007-11-05 at 09:52 +0000, Heikki Linnakangas wrote: >> It's not useful for VACUUM FREEZE, unless we're willing to freeze much >> more aggressively, and change the meaning of a set bit to "all tuples on >> heap page are frozen". > > This means that a regular VACUUM will no longer be enough to ensure > safety from transaction id wraparound. Good point. So we'd still need regular VACUUMs every now and then. (Gosh, we really need a name for the sort of vacuum. I was about to say "we'd still need regular regular VACUUMs" :-)) > I don't think this will be hard to fix, but it's an extra detail that > would need to be decided. The most apparent options appear to be: > > 1) Do as you say above. What are some of the cost trade-offs here? It > seems that frequent VACUUM FREEZE runs would keep the visibility map > mostly full, but will also cause more writing. I suppose the worst case > is that every tuple write needs results in two data page writes, one > normal write and another to freeze it later, which sounds bad. Maybe > there's a way to try to freeze the tuples on a page before it's written > out? It would also create more WAL traffic, because freezing tuples needs to be WAL-logged. > 2) Change to autovacuum to FREEZE on the forced autovacuum to prevent > wraparound. Doesn't necessarily need to be a VACUUM FREEZE. Just a "regular VACUUM" instead of using the visibility map. > 3) Use multiple bits per visibility map That would work. > 4) Have multiple types of visibility maps I'd rather not do that. It starts to get more complex and more expensive to update. 5) Have a more fine-grain equivalent of relfrozenxid. For example one frozenxid per visibility map page, so that whenever you update the visibility map, you also update the frozenxid. To advance the relfrozenxid in pg_class, you scan the visibility map and set relfrozenxid to the smallest frozenxid. Unlike relfrozenxid, it could be set to FrozenXid if the group of pages are totally frozen. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: