Re: index_interval

[Robert Coli <rc...@eventbrite.com>]

On Mon, May 13, 2013 at 9:19 PM, Bryan Talbot <bt...@aeriagames.com> wrote:
> Can the index sample storage be treated more like key cache or row cache
> where the total space used can be limited to something less than all
> available system ram, and space is recycled using an LRU (or configurable)
> algorithm?

Treating it with LRU doesn't seem to make that much sense, but there's
seemingly-trivial ways to prune an Index Sample [1] like
delete-every-other-key.

Brief conversation with driftx suggests a lack of enthusiasm for the
scale of win potential from active pruning of the Index Sample,
especially given the relative size of bloom filters compared to the
Index Sample.

However if you are interested in this as a potential improvement, feel
free to file a JIRA! :D

=Rob

[1] New terminology "Partition Summary" per jbellis keynote @ summit2013

Re: index_interval

[Thomas Bernhardt <be...@yahoo.com>]

________________________________
 From: Robert Coli <rc...@eventbrite.com>
To: user@cassandra.apache.org 
Sent: Monday, June 17, 2013 3:28 PM
Subject: Re: index_interval
 

On Mon, May 13, 2013 at 9:19 PM, Bryan Talbot <bt...@aeriagames.com> wrote:
> Can the index sample storage be treated more like key cache or row cache
> where the total space used can be limited to something less than all
> available system ram, and space is recycled using an LRU (or configurable)
> algorithm?

Treating it with LRU doesn't seem to make that much sense, but there's
seemingly-trivial ways to prune an Index Sample [1] like
delete-every-other-key.

Brief conversation with driftx suggests a lack of enthusiasm for the
scale of win potential from active pruning of the Index Sample,
especially given the relative size of bloom filters compared to the
Index Sample.

However if you are interested in this as a potential improvement, feel
free to file a JIRA! :D

=Rob

[1] New terminology "Partition Summary" per jbellis keynote @ summit2013