> 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. And we know
> that compression and encryption do not play well together. The reason
> compression was taken out of the latest TLS standards is not that they
> wouldn't have liked to have it, nor that applying compression in a separate
> code layer would be any safer. I fear offering this would merely lead people
> to build CVE-worthy setups.
>
I don't have a strong opinion on the patch but I'd just like to mention that there are definitely use cases for using
compressionon private networks (with ssl off). We have cases where we have a PG extension that hooks into the COPY ...
FROMcommand and accept lz4-compressed data for the COPY data message specifically. This has proven invaluable to us
evenon private networks, because it can give a good compression ratio for very little CPU decompression overhead.