On Sat, Jun 15, 2013 at 8:11 AM, Hannu Krosing <ha...@2ndquadrant.com> wrote: > Claiming that the algorithm will be one of only two (current and > "whatever algorithm we come up with ") suggests that it is > only one bit, which is undoubtedly too little for having a "pluggable" > compression API :)
See http://www.postgresql.org/message-id/20130607143053.gj29...@alap2.anarazel.de >> But those identifiers should be *small* (since they are added to all >> Datums) > if there will be any alignment at all between the datums, then > one byte will be lost in the noise ("remember: nobody will need > more than 256 compression algorithms") > OTOH, if you plan to put these format markers in the compressed > stream and change the compression algorithm while reading it, I am lost. The above-linked email addresses this point as well: there are bits available in the toast pointer. But there aren't MANY bits without increasing the storage footprint, so trying to do something that's more general than we really need is going to cost us in terms of on-disk footprint. Is that really worth it? And if so, why? I don't find the idea of a trade-off between compression/decompression speed and compression ratio to be very exciting. As Andres says, bzip2 is impractically slow for ... almost everything. If there's a good BSD-licensed algorithm available, let's just use it and be done. Our current algorithm has lasted us a very long time; I see no reason to think we'll want to change this again for another 10 years, and by that time, we may have redesigned the storage format altogether, making the limited extensibility of our current TOAST pointer format moot. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
