Re: pglz performance - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: pglz performance
Date
Msg-id 169163A8-C96F-4DBE-A062-7D1CECBE9E5D@yandex-team.ru
Whole thread Raw
In response to Re: pglz performance  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pglz performance
List pgsql-hackers

> 13 мая 2019 г., в 12:14, Michael Paquier <michael@paquier.xyz> написал(а):
>
> Decompression can matter a lot for mostly-read workloads and
> compression can become a bottleneck for heavy-insert loads, so
> improving compression or decompression should be two separate
> problems, not two problems linked.  Any improvement in one or the
> other, or even both, is nice to have.

Here's patch hacked by Vladimir for compression.

Key differences (as far as I see, maybe Vladimir will post more complete list of optimizations):
1. Use functions instead of macro-functions: not surprisingly it's easier to optimize them and provide less constraints
forcompiler to optimize. 
2. More compact hash table: use indexes instead of pointers.
3. More robust segment comparison: like memcmp, but return index of first different byte

In weighted mix of different data (same as for compression), overall speedup is x1.43 on my machine.

Current implementation is integrated into test_pglz suit for benchmarking purposes[0].

Best regards, Andrey Borodin.

[0] https://github.com/x4m/test_pglz

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Hypothetical indexes using BRIN broken since pg10
Next
From: Dave Cramer
Date:
Subject: Re: Fix doc bug in logical replication.