Re: [REVIEW] Re: Compression of full-page-writes

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [REVIEW] Re: Compression of full-page-writes
Дата
Msg-id CAB7nPqQbm5bveNSL3re6NGih2cSRyHqYdzek4pW2RyjDr3viWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [REVIEW] Re: Compression of full-page-writes  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [REVIEW] Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers


On Tue, Dec 16, 2014 at 11:24 PM, Alvaro Herrera <alvherre@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.
--
Michael

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: WALWriter active during recovery
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [alvherre@2ndquadrant.com: Re: no test programs in contrib]