Simon Riggs wrote:
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.
Actually, it would help even when full_page_writes=on, because even then
most xlog records don't have backup blocks attached to them.
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:
I think you got your alignment wrong:
pg_crc32 xl_crc; /* CRC for this record */
uint8 xl_info; /* flag bits, see below */
RmgrId xl_rmid; /* resource manager for this record */
Because of xl_prev below which is two uint32 fields, there will be 2
bytes of wasted space in here.
XLogRecPtr xl_prev; /* ptr to previous record in log */
TransactionId xl_xid; /* xact id */
uint32 xl_tot_len; /* total len of entire record */
ISTM that we would get the effect your looking for by just moving the
xl_tot_len field to the end, and only storing it for records with backup
blocks:
> pg_crc32 xl_crc; /* CRC for this record */
> XLogRecPtr xl_prev; /* ptr to previous record in log */
> TransactionId xl_xid; /* xact id */
> uint32 xl_len; /* total len of rmgr data */
> uint8 xl_info; /* flag bits, see below */
> RmgrId xl_rmid; /* resource manager for this record */
>> uint32 xl_tot_len; /* total len of entire record, if backup blocks
indicated in xl_info*/
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
