Daniel Gustafsson <daniel@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.