| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Даниил Захлыстов <usernamedt(at)yandex-team(dot)ru> |
| Subject: | Re: libpq compression |
| Date: | 2020-11-05 19:22:10 |
| Message-ID: | 5c832f37-db91-edec-3b31-7caef365df69@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-11-02 20:50, Andres Freund wrote:
> On 2020-10-31 22:25:36 +0500, Andrey Borodin wrote:
>> But the price of compression is 1 cpu for 500MB/s (zstd). With a
>> 20Gbps network adapters cost of recompressing all traffic is at most
>> ~4 cores.
>
> It's not quite that simple, because presumably each connection is going
> to be handled by one core at a time in the pooler. So it's easy to slow
> down peak throughput if you also have to deal with TLS etc.
Also, current deployments of connection poolers use rather small machine
sizes. Telling users you need 4 more cores per instance now to
decompress and recompress all the traffic doesn't seem very attractive.
Also, it's not unheard of to have more than one layer of connection
pooling. With that, this whole design sounds a bit like a
heat-generation system. ;-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-11-05 20:36:06 | list_free() in index_get_partition() |
| Previous Message | Peter Eisentraut | 2020-11-05 18:20:06 | Re: Move catalog toast table and index declarations |