Re: Freezing without write I/O
От | Simon Riggs |
---|---|
Тема | Re: Freezing without write I/O |
Дата | |
Msg-id | CA+U5nM+4dPvXHmo2UDH6gT4rNq4tYL7uQrVy8U3jQEAKqyeQKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Freezing without write I/O (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
On 30 May 2013 14:33, Heikki Linnakangas <hlinnakangas@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
В списке pgsql-hackers по дате отправления: