On Tue, Dec 16, 2014 at 11:30 PM, Michael Paquier <michael.paqu...@gmail.com
> wrote:
>
>
>
> On Tue, Dec 16, 2014 at 11:24 PM, Alvaro Herrera <alvhe...@2ndquadrant.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.
>
Actually, the original length of the compressed block in saved in
PGLZ_Header, so if we are fine to not check the size of the block
decompressed when decoding WAL we can do without the hole filled with
zeros, and use only 1 bit to see if the block is compressed or not.
--
Michael
