From opt_compression.mx:

@f opt_compression @- The compressed database Column stores mostly exploit some form of compression to reduce the footprint on disk and to improve disk/memory/cache bandwidth at the expense of cpu/memory cycles. A naive approach is to take a (*preferrably lightweight*) compression algorithm and deploy it against the units of access, e.g. disk/buffers. In MonetDB our granularity is a BAT, which therefore forms the basis for (de)compressed access. I don't know whether this is still an actively developed idea. If it is, perhaps this can help: http://code.google.com/p/snappy/ Roberto