[
https://issues.apache.org/jira/browse/CASSANDRA-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252793#comment-13252793
]
Jonathan Ellis commented on CASSANDRA-2635:
-------------------------------------------
Skimming this it looks like this turns off the cache hints for the read side as
well as for writes. I don't see any benefit to disabling it for reads -- if
there's nothing to evict the data, it won't get evicted even with the dontneed
hint. It's on the write side that we need to tell it, "go ahead and cache this
sstable that i'm writing now."
> make cache skipping optional
> ----------------------------
>
> Key: CASSANDRA-2635
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2635
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Peter Schuller
> Assignee: Harish Doddi
> Priority: Minor
> Attachments: CASSANDRA-2635-075.txt, CASSANDRA-2635-trunk-1.txt,
> CASSANDRA-2635-trunk.txt
>
>
> We've applied this patch locally in order to turn of page skipping; not
> completely but only for compaction/repair situations where it can be directly
> detrimental in the sense of causing data to become cold even though your
> entire data set fits in memory.
> It's better than completely disabling DONTNEED because the cache skipping
> does make sense and has no relevant (that I can see) detrimental effects in
> some cases, like when dumping caches.
> The patch is against 0.7.5 right now but if the change is desired I can make
> a patch for trunk. Also, the name of the configuration option is dubious
> since saying 'false' does not actually turn it off completely. I wasn't able
> to figure out a good name that conveyed the functionality in a short brief
> name however.
> A related concern as discussed in CASSANDRA-1902 is that the cache skipping
> isn't fsync:ing and so won't work reliably on writes. If the feature is to be
> retained that's something to fix in a different ticket.
> A question is also whether to retain the default to true or change it to
> false. I'm kinda leaning to false since it's detrimental in the "easy" cases
> of little data. In "big" cases with lots of data people will have to think
> and tweak anyway, so better to put the burden on that end.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
