Re: pglz performance

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: pglz performance
Дата
Msg-id 169163A8-C96F-4DBE-A062-7D1CECBE9E5D@yandex-team.ru
обсуждение исходный текст
Ответ на Re: pglz performance  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pglz performance  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Hypothetical indexes using BRIN broken since pg10
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: Fix doc bug in logical replication.