From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL Record Header Size Reduction |
Date: | 2007-01-25 14:56:24 |
Message-ID: | 1169736984.3772.160.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2007-01-25 at 14:04 +0000, Heikki Linnakangas wrote:
> 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.
Sure it would be active, but I meant it probably would not reduce the
overall WAL volume by very much. We'll see, I guess.
> > 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.
No escaping that though.
> 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*/
OK. I was assuming XLogRecPtr was 8-byte aligned, but its a struct with
2 4-byte aligned elements, so I thought I had to move it to get the
benefit. Seems not...
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-01-25 14:59:08 | Re: crash on 8.2 and cvshead - failed to add item to the left sibling |
Previous Message | Bruce Momjian | 2007-01-25 14:54:18 | Re: [HACKERS] Fix for bug in plpython bool type conversion |