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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend