Re: Teach pg_receivewal to use lz4 compression - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Teach pg_receivewal to use lz4 compression
Date
Msg-id CAFiTN-vXVgSGWy4n8qaX=+sPnGvcdEqtF==WsmpJ48utvqV9Zw@mail.gmail.com
Whole thread Raw
In response to Re: Teach pg_receivewal to use lz4 compression  (gkokolatos@pm.me)
Responses Re: Teach pg_receivewal to use lz4 compression  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Jul 8, 2021 at 7:48 PM <gkokolatos@pm.me> wrote:
>
> Dilip Kumar wrote:
>
> > Wouldn't it be better to call it compression method instead of
> > compression program?
>
> Agreed. This is inline with the suggestions of other reviewers.
> Find the change in the attached patch.

Thanks, I will have a look.

> > I think we can somehow use "acceleration" parameter of lz4 compression
> > to map on compression level, It is not direct mapping but
> > can't we create some internal mapping instead of completely ignoring
> > this option for lz4, or we can provide another option for lz4?
>
> We can, though I am not in favour of doing so. There is seemingly
> little benefit for added complexity.

I am really not sure what complexity you are talking about, do you
mean since with pglz we were already providing the compression level
so let it be as it is but with the new compression method you don't
see much benefit of providing compression level or speed?

> > Should we also support LZ4 compression using dictionary?
>
> I would we should not do that. If my understanding is correct,
> decompression would require the dictionary to be passed along.
> The algorithm seems to be very competitive to the current compression
> as is.

I agree, we might not go for a dictionary because we would need to
dictionary to decompress as well.  So that will add an extra
complexity for user.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: More time spending with "delete pending"
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side