Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
От | Jeff Davis |
---|---|
Тема | Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? ) |
Дата | |
Msg-id | 1250202043.24981.62.camel@monkey-cat.sm.truviso.com обсуждение исходный текст |
Ответ на | Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? ) (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
|
Список | pgsql-hackers |
On Thu, 2009-08-13 at 17:58 -0400, Alvaro Herrera wrote: > The most widely cited reason is that you lose forensics data. Although > they are increasingly rare, there are still situations in which the heap > tuple machinery messes up and the xmin/xmax/etc fields of the tuple are > the best/only way to find out what happened and thus fix the bug. If > you freeze early, there's just no way to know. As it stands, it looks like it's not just one extra write for each buffer, but potentially many (theoretically, as many as there are tuples on a page). I suppose the reasoning is that tuples on the same page have approximately the same xmin, and are likely to be frozen at the same time. But it seems entirely reasonable that the xmins on one page span several VACUUM runs, and that seems more likely with the FSM. That means that a few tuples on the page are older than 100M and get frozen, and the rest are only about 95M transactions old, so we have to come back and freeze them again, later. Let's say that we had a range like 50-100M, where if it's older than 100M, we freeze it, and if it's older than 50M we freeze it only if it's on a dirty page. We would still have forensic evidence, but we could make a range such that we avoid writing multiple times. And people who don't care about forensic evidence can set it to 0-100M. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: