Re: Compression of full-page-writes

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Compression of full-page-writes
Дата
Msg-id CAA4eK1JVn89xNT295ngKu8tab-Uu-A+CACNkYj8AnfVuCh1RwA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Compression of full-page-writes  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
Re: Compression of full-page-writes  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Mon, Dec 8, 2014 at 3:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On 8 December 2014 at 11:46, Michael Paquier <michael.paquier@gmail.com> wrote:
> > I don't really like those new names, but I'd prefer
> > wal_compression_level if we go down that road with 'none' as default
> > value. We may still decide in the future to support compression at the
> > record level instead of context level, particularly if we have an API
> > able to do palloc_return_null_at_oom, so the idea of WAL compression
> > is not related only to FPIs IMHO.
>
> We may yet decide, but the pglz implementation is not effective on
> smaller record lengths. Nor has any testing been done to show that is
> even desirable.
>

It's even much worse for non-compressible (or less-compressible)
WAL data.  I am not clear here that how a simple on/off switch
could address such cases because the data could be sometimes
dependent on which table user is doing operations (means schema or
data in some tables are more prone for compression in which case
it can give us benefits).  I think may be we should think something on
lines what Robert has touched in one of his e-mails (context-aware
compression strategy).


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: moving from contrib to bin
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: moving from contrib to bin