On 2013-06-15 13:11:47 +0200, Hannu Krosing wrote:
> If it were truly pluggable - that is just load a .dll, set a GUG and start
> using it
Ok. I officially rechristen the patchset to 'extensible compression
support'.
> - then the selection of algorithms would be much
> wider as several slow-but-high-compression ones under GPL could be
> used as well, similar to how currently PostGIS works.
> gzip and bzip2 are the first two that came in mind, but I am sure there
> are more.
gzip barely has a higher compression ratio than lz4 and is a magnitude
slower decompressing, so I don't think it's interesting.
I personally think bzip2 is too slow to be useful, even for
decompression. What might be useful is something like lzma, but it's
implementation is so complex that I don't really want to touch it.
> > In the past, we've had a great deal of speculation about that legal
> > question from people who are not lawyers. Maybe it would be valuable
> > to get some opinions from people who ARE lawyers.
> Making a truly pluggable compression API delegates this question
> to end users.
>
> Delegation is good, as it lets you get done more :)
No. It increases the features complexity by a magnitude. That's not
good. And it means that about nobody but a few expert users will benefit
from it, so I am pretty strongly opposed.
You suddently need to solve the question of how the identifiers for
compression formats are allocated and preserved across pg_upgrade and
across machines.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services