Re: Freezing without write I/O

On 1 June 2013 19:48, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> On 31.05.2013 06:02, Robert Haas wrote:
>>
>> On Thu, May 30, 2013 at 2:39 PM, Robert Haas<robertmhaas@gmail.com>
>> wrote:
>>>
>>> Random thought: Could you compute the reference XID based on the page
>>> LSN?  That would eliminate the storage overhead.
>>
>>
>> After mulling this over a bit, I think this is definitely possible.
>> We begin a new "half-epoch" every 2 billion transactions.  We remember
>> the LSN at which the current half-epoch began and the LSN at which the
>> previous half-epoch began.  When a new half-epoch begins, the first
>> backend that wants to stamp a tuple with an XID from the new
>> half-epoch must first emit a "new half-epoch" WAL record, which
>> becomes the starting LSN for the new half-epoch.
>
>
> Clever! Pages in unlogged tables need some extra treatment, as they don't
> normally have a valid LSN, but that shouldn't be too hard.

I like the idea of using the LSN to indicate the epoch. It saves any
other work we might consider, such as setting page or tuple level
epochs.


>> We define a new page-level bit, something like PD_RECENTLY_FROZEN.
>> When this bit is set, it means there are no unfrozen tuples on the
>> page with XIDs that predate the current half-epoch.  Whenever we know
>> this to be true, we set the bit.  If the page LSN crosses more than
>> one half-epoch boundary at a time, we freeze the page and set the bit.
>>   If the page LSN crosses exactly one half-epoch boundary, then (1) if
>> the bit is set, we clear it and (2) if the bit is not set, we freeze
>> the page and set the bit.
>
>
> Yep, I think that would work. Want to write the patch, or should I? ;-)

If we set a bit, surely we need to write the page. Isn't that what we
were trying to avoid?

Why set a bit at all? If we know the LSN of the page and we know the
epoch boundaries, then we can work out when the page was last written
to and infer that the page is "virtually frozen".

As soon as we make a change to a "virtually frozen" page, we can
actually freeze it and then make the change.

But we still have the problem of knowing which pages have been frozen
and which haven't.

Can we clear up those points first? Or at least my understanding of them.

--Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services