On Thu, May 06, 2021 at 07:23:48PM +0530, Dilip Kumar wrote:
> I have fixed some comments offlist reported by Justin. Apart from
> that, I have also improved documentation and test case. Stil it has a
> lot of cleanup to be done but I am not planning to do that
> immediately.
I was testing the various compression algos we touch in core, and I am
not really convinced that we need more code to control that. First,
pglz is living as-is in the backend code for a very long time and no
one has expressed an interest in controlling the compression strategy
used AFAIK. On top of that, LZ4 outclasses it easily, so if there is
a need to worry about performance with the TOAST data, users could
just move to use LZ4.
+ if (strcmp(def->defname, "acceleration") == 0)
+ {
+ int32 acceleration =
+ pg_atoi(defGetString(def), sizeof(acceleration), 0);
+
+ if (acceleration < INT32_MIN || acceleration > INT32_MAX)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("unexpected value for lz4 compression acceleration: \"%s\"",
+ defGetString(def)),
+ errhint("expected value between INT32_MIN and
INT32_MAX")
+ ));
Then comes the part with LZ4 and its acceleration. The default
compression level used by LZ4 compresses data the most, and it is
already pretty cheap in CPU. Do you have cases where this would be
useful? Increasing the acceleration reduces the compression to be
close to zero, but if one cares about the compression cost, he/she
could fall back to the external storage for basically the same
effect. Is there really a use-case for something in-between?
--
Michael