On Tue, Dec 16, 2014 at 11:24 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
>
> Michael Paquier wrote:
>
> > And here are attached fresh patches reducing the WAL record size to what
> it
> > is in head when the compression switch is off. Looking at the logic in
> > xlogrecord.h, the block header stores the hole length and hole offset. I
> > changed that a bit to store the length of raw block, with hole or
> > compressed as the 1st uint16. The second uint16 is used to store the hole
> > offset, same as HEAD when compression switch is off. When compression is
> > on, a special value 0xFFFF is saved (actually only filling 1 in the 16th
> > bit is fine...). Note that this forces to fill in the hole with zeros and
> > to compress always BLCKSZ worth of data.
>
> Why do we compress the hole? This seems pointless, considering that we
> know it's all zeroes. Is it possible to compress the head and tail of
> page separately?
>
This would take 2 additional bytes at minimum in the block header,
resulting in 8 additional bytes in record each time a FPW shows up. IMO it
is important to check the length of things obtained when replaying WAL,
that's something the current code of HEAD does quite well.
--
Michael