From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com> |
Subject: | Re: Performance Improvement by reducing WAL for Update Operation |
Date: | 2014-01-14 19:45:33 |
Message-ID: | CA+TgmoYYj-KSe19PeXzjBk7N+JUZMApE96SLekECzXH4vnMamQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 14, 2014 at 1:16 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Tue, Jan 14, 2014 at 2:16 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, Jan 11, 2014 at 1:08 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>> Yes, currently this applies to update, what I have in mind is that
>>> in future if some one wants to use WAL compression for any other
>>> operation like 'full_page_writes', then it can be easily extendible.
>>>
>>> To be honest, I have not evaluated whether such a flag or compression
>>> would make sense for full page writes, but I think it should be possible
>>> while doing full page write (BkpBlock has RelFileNode) to check such a
>>> flag if it's present.
>>
>> Makes sense.
>
> So shall I change it to string instead of bool and keep the name as
> compress_wal or compress_wal_for_opr?
No. If we add full-page-write compression in the future, that can be
a separate option. But I doubt we'd want to set that at the table
level anyway; there's no particular reason that would be good for some
tables and bad for others (whereas in this case there is such a
reason).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-01-14 19:50:12 | Re: [PATCH] Doc fix for VACUUM FREEZE |
Previous Message | Kevin Grittner | 2014-01-14 19:40:38 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |