WAL Record Header Size Reduction

Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%, depending upon the application with performance gains in various
ways.

If full_page_writes = off then it this is true
xl_tot_len == xl_len + SizeOfXLogRecord
since there are no backup blocks. As a result, there is no loss in
resilience by removing this field.

xlog.h shows this definition currently:

typedef struct XLogRecord
{
pg_crc32 xl_crc; /* CRC for this record */
XLogRecPtr xl_prev; /* ptr to previous record in log */
TransactionId xl_xid; /* xact id */
uint32 xl_tot_len; /* total len of entire record */
uint32 xl_len; /* total len of rmgr data */
uint8 xl_info; /* flag bits, see below */
RmgrId xl_rmid; /* resource manager for this record */

/* Depending on MAXALIGN, there are either 2 or 6 wasted bytes here */

I propose to rearrange the XLogRecord structure to this:

pg_crc32 xl_crc; /* CRC for this record */
uint8 xl_info; /* flag bits, see below */
RmgrId xl_rmid; /* resource manager for this record */
XLogRecPtr xl_prev; /* ptr to previous record in log */
TransactionId xl_xid; /* xact id */
uint32 xl_tot_len; /* total len of entire record */

which will occupy 24 bytes, saving 4 bytes on 32-bit and 8 bytes on
64-bit architectures, once alignment is considered.

The xl_len field would be included only if backup blocks are included
with the record. This is already marked by flags in the xl_info field,
so no new flags are required.

These changes can be mostly isolated to xlog.c, since only XLogInsert(),
ReadRecord() and pg_resetxlog need to know about the changes. The xlog
record would dynamically adjust according to whether backup blocks are
present, so it can still work as full_page_writes is switched on/off by
user or during the period between start/stop backup.

The saving is only really relevant when full_page_writes = off, so I'm
not worried about changing the xlrec header in that case anyway.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com