Skip site navigation (1) Skip section navigation (2)

Re: Reducing size of WAL record headers

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reducing size of WAL record headers
Date: 2013-01-10 19:54:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan  9, 2013 at 05:06:49PM -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > 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.
> I think this is extremely premature, in view of the ongoing discussions
> about shoehorning logical replication and other kinds of data into the
> WAL stream.  It seems quite likely that we'll end up eating some of
> that padding space to support those features.  So whacking a lot of code
> around in service of squeezing the existing padding out could very
> easily end up being wasted work, in fact counterproductive if it
> degrades either code readability or robustness.
> Let's wait till we see where the logical rep stuff ends up before we
> worry about saving 4 bytes per WAL record.

Well, we have wal_level to control the amount of WAL traffic.  It is
hard to imagine we are going to want to ship logical WAL information by
default, so most people will not be using logical WAL and would see a
benefit from an optimized WAL stream?  

What percentage is 8-bytes in a typical WAL record?

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to


pgsql-hackers by date

Next:From: Merlin MoncureDate: 2013-01-10 20:01:21
Subject: Re: json api WIP patch
Previous:From: Jeff DavisDate: 2013-01-10 19:04:03
Subject: Re: Enabling Checksums

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group