Re: Faster compression, again

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: Faster compression, again
Дата
Msg-id CAAZKuFbaH2N+bSysom7gsgq+S_nffgGNb0do1KLBSHo05_QKkQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Faster compression, again  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Faster compression, again
Список pgsql-hackers
On Thu, Mar 15, 2012 at 3:14 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, Mar 14, 2012 at 6:06 PM, Daniel Farina <daniel@heroku.com> wrote:
>
>> If we're curious how it affects replication
>> traffic, I could probably gather statistics on LZO-compressed WAL
>> traffic, of which we have a pretty huge amount captured.
>
> What's the compression like for shorter chunks of data? Is it worth
> considering using this for the libpq copy protocol and therefore
> streaming replication also?

The overhead is between 1 and 5 bytes that reserve the high bit as a
continuation bit (so one byte for small data), and then straight into
data.  So I think it could be applied for most payloads that are a few
bytes wide.  Presumably that could be lifted, but the format
description only allows for 2**32 - 1 for the uncompressed size.

I'd really like to find a way to layer both message-oblivious and
message-aware transport under FEBE with both backend and frontend
support without committing the project to new code for-ever-and-ever.
I guess I could investigate it in brief now, unless you've already
thought about/done some work in that area.

-- 
fdr


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: foreign key locks, 2nd attempt
Следующее
От: "ktm@rice.edu"
Дата:
Сообщение: Re: Faster compression, again