[
https://issues.apache.org/jira/browse/CASSANDRA-16717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846006#comment-17846006
]
Jeremiah Jordan commented on CASSANDRA-16717:
---------------------------------------------
It’s not just about resolving multiple nodes, it is also about knowing if the
row exists on the current node such that you are returning null (row exists,
column does not) or returning nothing (row does not exist).
There should be ways to better optimize the ONE case that only queries some
columns, but it’s definitely not as simple as just setting the column filter.
> The fetching strategy can be optimized for CL.ONE and CL.LOCAL_ONE
> ------------------------------------------------------------------
>
> Key: CASSANDRA-16717
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16717
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Benjamin Lerer
> Assignee: Benjamin Lerer
> Priority: Normal
>
> The current {{ColumnFilter}} fetching strategy has been implemented in order
> to guaranty the CQL semantics around empty vs non-existing rows. It has also
> some importance regarding read-repair (CASSANDRA-16710). Nevertheless, reads
> at {{CL.ONE}} and at {{CL.LOCAL_ONE}} do not use read-repair and do not
> require more columns than the queried ones as those cannot be deleted by
> column deletions present on other nodes. By consequence, having
> {{ColumnFilter}} fetching only the queried columns should improve query
> speed, by reducing the number of SSTable reads for queries fetching specific
> rows and reducing the amound of data serialized and transfered between nodes
> (if the data is not local).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
