Re: WAL format and API changes (9.5)

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 04/03/2014 06:37 PM, Tom Lane wrote:
>> +1, but one important step here is finding the data to be replayed.
>> That is, a large part of the complexity of replay routines has to do
>> with figuring out which parts of the WAL record were elided due to
>> full-page-images, and locating the remaining parts. What can we do
>> to make that simpler?

> We can certainly add more structure to the WAL records, but any extra
> information you add will make the records larger. It might be worth it,
> and would be lost in the noise for more complex records like page
> splits, but we should keep frequently-used records like heap insertions
> as lean as possible.

Sure, but in simple WAL records there would just be a single data chunk
that would be present in the normal case and not present in the FPI case.
Seems like we ought to be able to handle that degenerate case with no
significant wastage (probably just a flag bit someplace).

More generally, I'm pretty sure that your proposal is already going to
involve some small growth of WAL records compared to today, but I think
that's probably all right; the benefits seem significant.

> Hmm. You could register a separate XLogRecData chain for each buffer.
> Plus one more chain for the data not associated with a buffer.

That would probably work.

regards, tom lane