On 1/30/13 3:28 PM, Kevin Grittner wrote:
Jim Nasby <j...@nasby.net> wrote:
then the *ideal* time to start a freeze vacuum on a table is so
that the vacuum would end *exactly* as we were about to hit XID
wrap.
For a tuple which you know is going to survive long enough to be
frozen, the *ideal* time to freeze a tuple, from a performance
standpoint, is when the tuple is written, to eliminate a separate
WAL-log operation. The *next best* time to freeze is when the hint
bits are set, to avoid a separate page write. If you are doing
differential backups, the *third best* time to freeze is before the
first differential backup of the tuple, to avoid a separate backup
after the freeze. And so on.
Yeah, I hadn't considered that aspect, but I think that's a separate
discussion. I agree that there are many cases where we would benefit
from freezing early, and those should all help reduce the impact of
XID-wrap induced freezing.
Even if we do introduce "up-front" freezing, we still need to deal with
all the other cases though, which in the worst case means avoiding the
XID wrap. I believe that particular case (as well as the whole autovac
priority question) would be best served by looking at 1st and 2nd order
derivatives.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
