[
https://issues.apache.org/jira/browse/CASSANDRA-14629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16961186#comment-16961186
]
Aleksey Yeschenko commented on CASSANDRA-14629:
-----------------------------------------------
Looks ok to me overall, but I do have two questions (two variations of the same
question, really):
1. {{select(DecoratedKey partitionKey, ClusteringIndexFilter clusteringFilter,
ColumnFilter columnFilter)}} involves invoking {{hasKey(DecoratedKey
partitionKey)}} and then {{getRows(DecoratedKey key, ClusteringIndexFilter
clusteringFilter, ColumnFilter columnFilter)}}. Depending on the underlying
implementation, this could mean a lot of extra work - up to doubling the amount
of work needed. As an illustration, a common {{Map}} usage antipattern comes to
mind: doing a {{contains()}} followed by {{get()}} instead of just doing get
and checking for {{null}}. I know that one of the use cases you have in mind
for this code is exposing the raw content of sstables, and I can see this
overhead being relatively significant there potentially. I would suggest
getting rid of {{hasKey()}} entirely and of the related check.
2. Similarly, {{select(DataRange dataRange, ColumnFilter columnFilter)}} and
{{getPartitionKeys(DataRange dataRange)}} invocation could maybe also be
remodelled to permit a single underlying iterator?
It's possible that I'm missing something here, so these aren't demands for
changes - just a conversation starter.
P.S. You can suppress the redundant suppression warnings themselves like this:
{code:java}
@SuppressWarnings({"resource", "RedundantSuppression"})
{code}
> Abstract Virtual Table for very large result sets
> -------------------------------------------------
>
> Key: CASSANDRA-14629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14629
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL, Legacy/Observability
> Reporter: Chris Lohfink
> Assignee: Chris Lohfink
> Priority: Low
> Labels: pull-request-available, virtual-tables
> Time Spent: 4h
> Remaining Estimate: 0h
>
> For virtual tables that are very large we cannot use existing
> abstractvirtualtable since it would OOM the node possibly. An example would
> be a table to view the internal cache contents or to view contents of
> sstables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
