On 30 May 2013 14:33, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > Since we're bashing around ideas around freezing, let me write down the idea > I've been pondering and discussing with various people for years. I don't > think I invented this myself, apologies to whoever did for not giving > credit. > > The reason we have to freeze is that otherwise our 32-bit XIDs wrap around > and become ambiguous. The obvious solution is to extend XIDs to 64 bits, but > that would waste a lot space. The trick is to add a field to the page header > indicating the 'epoch' of the XID, while keeping the XIDs in tuple header > 32-bit wide (*). > > The other reason we freeze is to truncate the clog. But with 64-bit XIDs, we > wouldn't actually need to change old XIDs on disk to FrozenXid. Instead, we > could implicitly treat anything older than relfrozenxid as frozen. > > That's the basic idea. Vacuum freeze only needs to remove dead tuples, but > doesn't need to dirty pages that contain no dead tuples.
I have to say this is pretty spooky. I'd not read hackers all week, so I had no idea so many other people were thinking about freezing as well. This idea is damn near identical to what I've suggested. My suggestion came because I was looking to get rid of fields out of the tuple header; which didn't come to much. The good news is that is complete chance, so it must mean we're on the right track. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
