[ 
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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to