I believe the timestamps *on per column basis* are only required until the compaction time after that it may also work if the timestamp range could be specified globally on per SST table basis. and thus the timestamps until compaction are only required to be measure the time from the initialization of the new memtable to the point the column is written to that memtable. Thus you can easily fit that time in 4 bytes. This I believe would save atleast 4 bytes overhead for each column.
Is anything related to these overheads under consideration/ or planned in the roadmap ? On Tue, Sep 6, 2011 at 11:44 AM, Oleg Anastastasyev <olega...@gmail.com> wrote: > >> >> I have a patch for trunk which I just have to get time to test a bit before I > submit. >> It is for super columns and will use the super columns timestamp as the base > and only store variant encoded offsets in the underlying columns. >> > > Could you please measure how much real benefit it brings (in real RAM > consumption by JVM). It is hard to tell will it give noticeable results or > not. > AFAIK memory structures used for memtable consume much more memory. And 64-bit > JVM allocates memory aligned to 64-bit word boundary. So 37% of memory > consumption reduction looks doubtful. > >
