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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
