Re: Performance Improvement by reducing WAL for Update Operation
От | Robert Haas |
---|---|
Тема | Re: Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | CA+TgmoYYj-KSe19PeXzjBk7N+JUZMApE96SLekECzXH4vnMamQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Performance Improvement by reducing WAL for Update Operation (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jan 14, 2014 at 1:16 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Tue, Jan 14, 2014 at 2:16 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Sat, Jan 11, 2014 at 1:08 AM, Amit Kapila <amit.kapila16@gmail.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
В списке pgsql-hackers по дате отправления: