On Thu, May 30, 2013 at 3:22 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-05-30 14:39:46 -0400, Robert Haas wrote:
>> > Since we're not storing 64-bit wide XIDs on every tuple, we'd still need to
>> > replace the XIDs with FrozenXid whenever the difference between the smallest
>> > and largest XID on a page exceeds 2^31. But that would only happen when
>> > you're updating the page, in which case the page is dirtied anyway, so it
>> > wouldn't cause any extra I/O.
>>
>> It would cause some extra WAL activity, but it wouldn't dirty the page
>> an extra time.
>
> You probably could do it similarly to how we currently do
> XLOG_HEAP_ALL_VISIBLE_CLEARED and just recheck the page on replay. The
> insert/update/delete record will already contain a FPI if necessary, so
> that should be safe.
Ah, good point.
>> > This would also be the first step in allowing the clog to grow larger than 2
>> > billion transactions, eliminating the need for anti-wraparound freezing
>> > altogether. You'd still want to truncate the clog eventually, but it would
>> > be nice to not be pressed against the wall with "run vacuum freeze now, or
>> > the system will shut down".
>
>> Interesting. That seems like a major advantage.
>
> Hm. Why? If freezing gets notably cheaper I don't really see much need
> for keeping that much clog around? If we still run into anti-wraparound
> areas, there has to be some major operational problem.
That is true, but we have a decent number of customers who do in fact
have such problems. I think that's only going to get more common. As
hardware gets faster and PostgreSQL improves, people are going to
process more and more transactions in shorter and shorter periods of
time. Heikki's benchmark results for the XLOG scaling patch show
rates of >80,000 tps. Even at a more modest 10,000 tps, with default
settings, you'll do anti-wraparound vacuums of the entire cluster
about every 8 hours. That's not fun.
Being able to do such scans only of the not-all-visible pages would be
a huge step forward, of course. But not having to do them on any
particular deadline would be a whole lot better.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
