From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Compression of full-page-writes |
Date: | 2013-08-30 05:55:31 |
Message-ID: | CAHGQGwFs0b95FZO9tPNOxTnKLSWHytjJrMYK8tqMGWxKOykXcQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 30, 2013 at 12:43 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Thu, Aug 29, 2013 at 7:55 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> [the amount of WAL generated during running pgbench]
>> 4302 MB (compress_backup_block = off)
>> 1521 MB (compress_backup_block = on)
>
> Interesting.
>
> I wonder, what is the impact on recovery time under the same
> conditions?
Will test! I can imagine that the recovery time would be a bit
longer with compress_backup_block=on because compressed
FPW needs to be decompressed.
> I suppose that the cost of the random I/O involved would
> probably dominate just as with compress_backup_block = off. That said,
> you've used an SSD here, so perhaps not.
Oh, maybe my description was confusing. full_page_writes was enabled
while running the benchmark even if compress_backup_block = off.
I've not merged those two parameters yet. So even in
compress_backup_block = off, random I/O would not be increased in recovery.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2013-08-30 06:02:09 | Re: Compression of full-page-writes |
Previous Message | Michael Paquier | 2013-08-30 05:55:23 | Re: Compression of full-page-writes |