On 06/15/2013 03:56 AM, Robert Haas wrote: > On Fri, Jun 14, 2013 at 8:45 PM, Andres Freund <and...@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Ü -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers