Re: pglz compression performance, take two

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: pglz compression performance, take two
Дата
Msg-id 91F7608D-4800-49B8-B5EC-911AAF1BB069@enterprisedb.com
обсуждение исходный текст
Ответ на Re: pglz compression performance, take two  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: pglz compression performance, take two  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers

> On Jan 28, 2021, at 2:56 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>
>> 22 янв. 2021 г., в 07:48, Justin Pryzby <pryzby@telsasoft.com> написал(а):
>>
>> @cfbot: rebased
>> <0001-Reorganize-pglz-compression-code.patch>
>
> Thanks!
>
> I'm experimenting with TPC-C over PostgreSQL 13 on production-like cluster in the cloud. Overall performance is
IO-bound,but compression is burning a lot energy too (according to perf top). Cluster consists of 3 nodes(only HA, no
standbyqueries) with 32 vCPU each, 128GB RAM, sync replication, 2000 warehouses, 240GB PGDATA. 
>
> Samples: 1M of event 'cpu-clock', 4000 Hz, Event count (approx.): 177958545079
> Overhead  Shared Object                                     Symbol
>  18.36%  postgres                                          [.] pglz_compress
>   3.88%  [kernel]                                          [k] _raw_spin_unlock_irqrestore
>   3.39%  postgres                                          [.] hash_search_with_hash_value
>   3.00%  [kernel]                                          [k] finish_task_switch
>   2.03%  [kernel]                                          [k] copy_user_enhanced_fast_string
>   1.14%  [kernel]                                          [k] filemap_map_pages
>   1.02%  postgres                                          [.] AllocSetAlloc
>   0.93%  postgres                                          [.] _bt_compare
>   0.89%  postgres                                          [.] PinBuffer
>   0.82%  postgres                                          [.] SearchCatCache1
>   0.79%  postgres                                          [.] LWLockAttemptLock
>   0.78%  postgres                                          [.] GetSnapshotData
>
> Overall cluster runs 862tps (52KtpmC, though only 26KtmpC is qualified on 2K warehouses).
>
> Thanks!

Robert Haas just committed Dilip Kumar's LZ4 compression, bbe0a81db69bd10bd166907c3701492a29aca294.

Is this pglz compression patch still relevant?  How does the LZ4 compression compare on your hardware?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] Identify LWLocks in tracepoints
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Custom compression methods