Re: pglz performance - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pglz performance
Date
Msg-id 6d5eb102-87e5-9dc8-3cf0-dd218e65ab18@2ndquadrant.com
Whole thread Raw
In response to Re: pglz performance  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: pglz performance
List pgsql-hackers
On 2019-09-04 14:45, Andrey Borodin wrote:
>> On 2019-09-04 11:22, Andrey Borodin wrote:
>>>> What about the two patches?  Which one is better?
>>> On our observations pglz_decompress_hacked.patch is best for most of tested platforms.
>>> Difference is that pglz_decompress_hacked8.patch will not appply optimization if decompressed match is not greater
than8 bytes. This optimization was suggested by Tom, that's why we benchmarked it specifically.
 
>>
>> The patches attached to the message I was replying to are named
>>
>> 0001-Use-memcpy-in-pglz-decompression-for-long-matches.patch
>> 0001-Use-memcpy-in-pglz-decompression.patch
>>
>> Are those the same ones?
> 
> Yes. Sorry for this confusion.
> 
> The only difference of 0001-Use-memcpy-in-pglz-decompression-for-long-matches.patch is that it fallbacks to byte-loop
iflen is <= 8.
 

After reviewing this thread and more testing, I think
0001-Use-memcpy-in-pglz-decompression.patch appears to be a solid win
and we should move ahead with it.

I don't, however, fully understand the code changes, and I think this
could use more and better comments.  In particular, I wonder about

off *= 2;

This is new logic that isn't explained anywhere.

This whole function is commented a bit strangely.  It begins with
"Otherwise", but there is nothing before it.  And what does "from OUTPUT
to OUTPUT" mean?  There is no "output" variable.  We should make this
match the code better.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_wal/RECOVERYHISTORY file remains after archive recovery
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooler