On Tue, Nov 9, 2021 at 7:02 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniel Gustafsson <dan...@yesql.se> writes: > > 2773: libpq compression > > ======================= > > This patch intended to provide libpq connection compression to "replace > SSL > > compression" which was doomed when the patch was written, and have since > been > > removed altogether. The initial approach didn't get much traction but > there > > was significant discussion and work, which has since fizzled out. The > patch > > has been updated but there hasn't been meaningful review the past > months, the > > last comments seem to imply there being a fair amount of questionmarks > left in > > here. Robert, having been very involved in this do you have any > thoughts on > > where we are and where to go (if at all IYO)? > > I'm not Robert, but I still have an opinion here, and that it's that this > feature would at best be an attractive nuisance. If you need compression > on a database session, it probably means that the connection is over the > open internet, which means that you need encryption even more. >
This assumption is very vague. I personally had multiple cases when network bandwidth for app <--> Postgres communication, that were fixed wither via upgrades (spending more money) or making application developers cache more data (optimization), or, usually, both. Never public internet connections were involved. Actually, any growing startup experiences such issues sooner or later. Network compression would be a great tool for many setups, and some other popular database systems offer it for a long.