On 09.01.2013 22:59, Bruce Momjian wrote:
> On Wed, Jan 9, 2013 at 10:54:33PM +0200, Heikki Linnakangas wrote:
>> On 09.01.2013 22:36, Simon Riggs wrote:
>>> The WAL record header starts with xl_tot_len, a 4 byte field. There is
>>> also another field, xl_len. The difference is that xl_tot_len includes
>>> the header, xl_len and any backup blocks. Since the header is fixed,
>>> the only time xl_tot_len != SizeOfXLogRecord + xl_len is when we have
>>> backup blocks.
>>>
>>> We can re-arrange the record layout so that we remove xl_tot_len and
>>> add another (maxaligned) 4 byte field (--> 8 bytes) after the record
>>> header, xl_bkpblock_len that only exists if we have backup blocks.
>>> This will then save 8 bytes from every record that doesn't have backup
>>> blocks, and be the same as now with backup blocks.
>>
>> Here's a better idea:
>>
>> Let's keep xl_tot_len as it is, but move xl_len at the very end of
>> the WAL record, after all the backup blocks. If there are no backup
>> blocks, xl_len is omitted. Seems more robust to keep xl_tot_len, so
>> that you require less math to figure out where one record ends and
>> where the next one begins.
>
> OK, crazy idea, but can we just record xl_len as a difference against
> xl_tot_len, and shorten the xl_len field?
Hmm, so it would essentially be the length of all the backup blocks.
perhaps rename it to xl_bkpblk_len.
However, that would cap the total size of backup blocks to 64k. Which
would not be enough with 32k BLCKSZ.
- Heikki