Joachim Wieland <j...@mcknight.de> writes: > If we still cannot do this, then what I am asking is: What does the > project need to be able to at least link against such a compression > algorithm?
Well, what we *really* need is a convincing argument that it's worth taking some risk for. I find that not obvious. You can pipe the output of pg_dump into your-choice-of-compressor, for example, and that gets you the ability to spread the work across multiple CPUs in addition to eliminating legal risk to the PG project. And in any case the general impression seems to be that the main dump-speed bottleneck is on the backend side not in pg_dump's compression. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers