Hello,
I would like to contribute few points.

>XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn)
>               RedoRecPtr = Insert->RedoRecPtr;
>       }
>       doPageWrites = (Insert->fullPageWrites || Insert->forcePageWrites);
>       doPageCompression = (Insert->fullPageWrites == 
> FULL_PAGE_WRITES_COMPRESS);

Don't we need to initialize doPageCompression  similar to doPageWrites in 
InitXLOGAccess?

Also , in the earlier patches compression was set 'on' even when fpw GUC is 
'off'. This was to facilitate compression of FPW which are forcibly written 
even when fpw GUC is turned off.
 doPageCompression in this patch is set to true only if value of fpw GUC is 
'compress'. I think its better to compress forcibly written full page writes.


Regards,

Rahila Syed
-----Original Message-----
From: pgsql-hackers-ow...@postgresql.org 
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
Sent: Wednesday, November 26, 2014 1:55 PM
To: Alvaro Herrera
Cc: Andres Freund; Robert Haas; Fujii Masao; Rahila Syed; Rahila Syed; 
PostgreSQL-development
Subject: Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

So, Here are reworked patches for the whole set, with the following changes:
- Found why replay was failing, xlogreader.c took into account BLCKSZ
- hole while it should have taken into account the compressed data length when 
fetching a compressed block image.
- Reworked pglz portion to have it return status errors instead of simple 
booleans. pglz stuff is as well moved to src/common as Alvaro suggested.

I am planning to run some tests to check how much compression can reduce WAL 
size with this new set of patches. I have been however able to check that those 
patches pass installcheck-world with a standby replaying the changes behind. 
Feel free to play with those patches...
Regards,
--
Michael

______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to