Re: pglz compression performance, take two - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: pglz compression performance, take two
Date
Msg-id CAAhFRxg+YdBm5jF=cu_Ca22JFSOmE11xP_L8ty6poH4QUHMMdA@mail.gmail.com
Whole thread Raw
In response to Re: pglz compression performance, take two  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
On Mon, Feb 6, 2023 at 11:57 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
>
> I wonder what that means for the patch. I haven't investigated this at
> all, but it seems as if the optimization means we fail to find a match,
> producing a tad larger output. That may be still be a good tradeoff, as
> long as the output is correct (assuming it doesn't break some promise
> regarding expected output).
>

Yes, patch produces correct results and faster. And keeps the
compression ratio the same except for some one odd case.
The only problem is I do not understand _why_ it happens in that odd
case. And so far I failed to extract input\outputs of that odd case,
because it is buried under so many layers of abstraction and affects
only late stats.
Maybe the problem is not in compression at all...

Best regards, Andrey Borodin.



pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Pluggable toaster
Next
From: Nikita Malakhov
Date:
Subject: Re: Pluggable toaster