Re: [REVIEW] Re: Compression of full-page-writes
От | Andres Freund |
---|---|
Тема | Re: [REVIEW] Re: Compression of full-page-writes |
Дата | |
Msg-id | 20141127144258.GA5164@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [REVIEW] Re: Compression of full-page-writes (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [REVIEW] Re: Compression of full-page-writes
|
Список | pgsql-hackers |
On 2014-11-27 13:00:57 +0900, Michael Paquier wrote: > On Wed, Nov 26, 2014 at 8:27 PM, Syed, Rahila <Rahila.Syed@nttdata.com> wrote: > > Don't we need to initialize doPageCompression similar to doPageWrites in InitXLOGAccess? > Yep, you're right. I missed this code path. > > > Also , in the earlier patches compression was set 'on' even when fpw GUC is 'off'. This was to facilitate compressionof 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 compressforcibly written full page writes. > Meh? (stealing a famous quote). > This is backward-incompatible in the fact that forcibly-written FPWs > would be compressed all the time, even if FPW is set to off. The > documentation of the previous patches also mentioned that images are > compressed only if this parameter value is switched to compress. err, "backward incompatible"? I think it's quite useful to allow compressing newpage et. al records even if FPWs aren't required for the hardware. One thing Heikki brought up somewhere, which I thought to be a good point, was that it might be worthwile to forget about compressing FDWs themselves, and instead compress entire records when they're large. I think that might just end up being rather beneficial, both from a code simplicity and from the achievable compression ratio. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: