Re: [REVIEW] Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [REVIEW] Re: Compression of full-page-writes
Date
Msg-id CAB7nPqQeinmb1RPGq=r__kJHdpihnjpp_09-WssfpoyDuMqPmA@mail.gmail.com
Whole thread Raw
In response to Re: [REVIEW] Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Proposal: Log inability to lock pages during vacuum
Next
From: Greg Stark
Date:
Subject: Re: BRIN indexes - TRAP: BadArgument