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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
