On 06/15/2013 03:56 AM, Robert Haas wrote:
> On Fri, Jun 14, 2013 at 8:45 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> On 2013-06-14 17:35:02 -0700, Josh Berkus wrote:
>>>> No. I think as long as we only have pglz and one new algorithm (even if
>>>> that is lz4 instead of the current snappy) we should just always use the
>>>> new algorithm. Unless I missed it nobody seemed to have voiced a
>>>> contrary position?
>>>> For testing/evaluation the guc seems to be sufficient.
>>> Then it's not "pluggable", is it? It's "upgradable compression
>>> support", if anything. Which is fine, but let's not confuse people.
>> The point is that it's pluggable on the storage level in the sense of
>> that several different algorithms can coexist and new ones can
>> relatively easily added.
>> That part is what seems to have blocked progress for quite a while
>> now. So fixing that seems to be the interesting thing.
>>
>> I am happy enough to do the work of making it configurable if we want it
>> to be... But I have zap interest of doing it and throw it away in the
>> end because we decide we don't need it.
> I don't think we need it. I think what we need is to decide is which
> algorithm is legally OK to use. And then put it in.
If it were truly pluggable - that is just load a .dll, set a GUG and start
using it - 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.
> 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 :)
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ