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
