On Mon, Nov 19, 2012 at 6:17 AM, Andras Szerdahelyi < [email protected]> wrote:
> How is the "saved row cache file" processed? Are the cached row keys > simply iterated over and their respective rows read from SSTables - > possibly creating random reads with small enough sstable files, if the keys > were not stored in a manner optimised for a quick re-fill ? - or is there > a smarter algorithm ( i.e. scan through one sstable at a time, filter rows > that should be in row cache ) at work and this operation is purely disk > i/o bound ? > Nope, that's it. I am quite confident that in the version you are running, it just assembles the row from disk, from the relevant SSTables, via the more or less normal read path. The more fragmented your sstables, the more random the i/o. These two 1.2.x era JIRA relate to the row cache startup penalty : https://issues.apache.org/jira/browse/CASSANDRA-4282 # multi-threaded row cache loading at startup https://issues.apache.org/jira/browse/CASSANDRA-3762 # improvements to the AutoSavingCache (which is the base class of AutoSavingRowCache) =Rob -- =Robert Coli AIM>ALK - [email protected] YAHOO - rcoli.palominob SKYPE - rcoli_palominodb
