On Wed, Jan 9, 2013 at 10:54:33PM +0200, Heikki Linnakangas wrote: > On 09.01.2013 22:36, Simon Riggs wrote: > >Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we > >waste 4 bytes per record. Or put another way, if we could reduce > >record header by 4 bytes, we would actually reduce it by 8 bytes per > >record. So looking for ways to do that seems like a good idea. > > Agreed. > > >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? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers