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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [REVIEW] Re: Compression of full-page-writes
Дата
Msg-id CAB7nPqQeinmb1RPGq=r__kJHdpihnjpp_09-WssfpoyDuMqPmA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [REVIEW] Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [REVIEW] Re: Compression of full-page-writes  (Amit Langote <amitlangote09@gmail.com>)
Re: [REVIEW] Re: Compression of full-page-writes  (Rahila Syed <rahilasyed.90@gmail.com>)
Re: [REVIEW] Re: Compression of full-page-writes  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Nov 10, 2014 at 5:26 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> I'll go through the patch once again a bit later, but feel free to comment.
Reading again the patch with a fresher mind, I am not sure if the
current approach taken is really the best one. What the patch does now
is looking at the header of the first backup block, and then
compresses the rest, aka the other blocks, up to 4, and their headers,
up to 3. I think that we should instead define an extra bool flag in
XLogRecord to determine if the record is compressed, and then use this
information. Attaching the compression status to XLogRecord is more
in-line with the fact that all the blocks are compressed, and not each
one individually, so we basically now duplicate an identical flag
value in all the backup block headers, which is a waste IMO.
Thoughts?
-- 
Michael



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Proposal: Log inability to lock pages during vacuum
Следующее
От: Greg Stark
Дата:
Сообщение: Re: BRIN indexes - TRAP: BadArgument