[
https://issues.apache.org/jira/browse/CASSANDRA-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1267:
--------------------------------------
Attachment: 1267-v2.txt
Good start. Here's my take on it:
1) the business about counting only live columns is not optional; it breaks
tests to take it out
2) we can optimize removeDeleted more by not adding irrelevant columns in the
first place
3) we can simplify things by making callers who don't want the source CF
modified explicitly clone first. (this is just test code.)
4) gcBefore is strictly increasing in real code, so directly modifying the
cached row during removeDeleted is OK; test code can work around w/ (3) above
v2 attached. [(2) is done by splitting rD into rDCF and rDColumnsOnly. full
rD is only needed for supercolumn rows, since "don't add irrelevant subcolumns"
is hard.]
> Improve performance of cached row slices
> ----------------------------------------
>
> Key: CASSANDRA-1267
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1267
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Priority: Minor
> Fix For: 0.7
>
> Attachments: 1267-v2.txt, cached-row-slice-perf-patch-1.txt
>
>
> In Lucandra, I have a use case to pull all columns for a given row.
> I've noticed that for rows with large numbers of columns this takes much
> longer than I would think since row caching is enabled.
> After looking into this I see that the cached row is rebuilt and pruned even
> though I want all columns.
> This patch skips this use case and in my case has improved performance
> significantly.
> From ~400ms to ~50ms
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
