On Fri, Nov 5, 2010 at 2:41 PM, Jeremy Davis
wrote:
> What do you mean by "Turning Over quickly"? What is Turning over? If it
> needs to create an entirely new row, then that would create GC pressure for
> sure... But if you are just updating a column in a row that is already in
> the cache, then
> In short, it seems like the general advice is unless you have a set of nearly
> static rows, AND they all fit in the cache, then rowcache is not recommended.
That's been our experience. Leave the memory for the OS cache instead.
Dave
On Friday, November 5, 2010, Jeremy Davis wrote:
> What do
What do you mean by "Turning Over quickly"? What is Turning over? If it
needs to create an entirely new row, then that would create GC pressure for
sure... But if you are just updating a column in a row that is already in
the cache, then I would think that would be the optimal situation.
OTOH, you
On Fri, Nov 5, 2010 at 1:41 PM, Jeremy Davis
wrote:
> I saw in the Riptano "Tuning Cassandra" slide deck that the row cache can
> be detrimental if there are a lot of updates to the cached row. Is this
> because the cache is not write through, and every update necessitates
> creation of a new row?
I saw in the Riptano "Tuning Cassandra" slide deck that the row cache can be
detrimental if there are a lot of updates to the cached row. Is this because
the cache is not write through, and every update necessitates creation of a
new row?
I see there is an open issue:
https://issues.apache.org/jira
