From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Idea for getting rid of VACUUM FREEZE on cold pages |
Date: | 2010-05-25 17:10:35 |
Message-ID: | 1274807228-sup-3161@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Heikki Linnakangas's message of mar may 25 04:41:30 -0400 2010:
> On 24/05/10 22:49, Alvaro Herrera wrote:
> > I think this is nonsense. If you have 3-years-old sales transactions,
> > and your database has any interesting churn, tuples those pages have
> > been frozen for a very long time *already*.
> What's missing from the suggestion is that relfrozenxid and datfrozenxid
> also need to be expanded to 8-bytes. That way you effectively have
> 8-byte XIDs, which means that you never need to vacuum to avoid XID
> wraparound.
Hmm, so are we going to use the "xid epoch" more officially? That's
entirely a new line of development, perhaps it opens new possibilities.
This sounds like extending Xid to 64 bits, without having to store the
high bits everywhere. Was this discussed in the PGCon devs meeting?
--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-05-25 17:31:48 | Re: Synchronization levels in SR |
Previous Message | Simon Riggs | 2010-05-25 17:10:08 | Re: Synchronization levels in SR |