> 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. --
