On 2013-06-14 17:12:01 -0700, Josh Berkus wrote: > On 06/14/2013 04:01 PM, Andres Freund wrote: > > It still contains a guc as described in the above message to control the > > algorithm used for compressing new tuples but I think we should remove > > that guc after testing. > > Did you add the storage attribute?
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. If we want to make it configurable on a per column basis I think the way to go is to add a new column to pg_attribute and split compression related things out of attstorage into attcompression. That's a fair amount of work and it includes a minor compatibility break in the catalog format, so I'd prefer not to do it until there's a good reason to do so. 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
