On Mon, Jul 12, 2021 at 11:33 AM <gkokolatos@pm.me> wrote:
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Monday, July 12th, 2021 at 07:56, Michael Paquier <michael@paquier.xyz> wrote:
>
> > On Mon, Jul 12, 2021 at 11:10:24AM +0530, Dilip Kumar wrote:
> >
> > > On Thu, Jul 8, 2021 at 7:48 PM gkokolatos@pm.me wrote:
> > >
> > > > 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?
> >
> > You mean s/pglz/zlib/ here perhaps? I am not sure what Georgios has
> >
> > in mind, but my opinion stands on the latter: there is little benefit
> >
> > in making lz4 faster than the default and reduce compression, as the
> >
> > default is already a rather low CPU user.
>
> Thank you all for your comments. I am sitting on the same side as Micheal
> on this one. The complexity is not huge, yet there will need to be code to
> pass this option to the lz4 api and various test cases to verify for
> correctness and integrity. The burden of maintenance of this code vs the
> benefit of the option, tilt the scale towards not including the option.
+1 for skipping that one, at least for now, and sticking to
default-only for lz4.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
