[
https://issues.apache.org/jira/browse/CASSANDRA-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-8859.
-----------------------------------------
Resolution: Duplicate
This is actually a duplicate of CASSANDRA-7085. Basically, we do query all
columns of a row internally for reasons pertaining to the CQL semantic. This
should get fixed in 3.0 (by CASSANDRA-8099 in fact), but their is no simple
solution for 2.0/2.1.
> CollationController not using collectTimeOrderedData
> ----------------------------------------------------
>
> Key: CASSANDRA-8859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8859
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Michael Mior
> Priority: Minor
>
> I'd appreciate some help with a Cassandra 2.1.2 issue I'm experiencing. I'm
> running a query which looks like this:
> {code}
> CREATE TABLE single_row_fetch (id uuid PRIMARY KEY, data text)
> SELECT data FROM single_row_fetch WHERE id = ?
> {code}
> When writing test data into this table, I disabled compaction. I then wrote
> data for performed a flush, and then overwrote the data, and so on. I varied
> the number of times the data was overwritten and flushed. This has the effect
> of controlling the number of SSTables. However, given that the table only has
> one non-key row, only a single SSTable will ever have the most recent data
> for this row. I confirmed that the expected number of SSTables were generated
> and the timestamps of the are as expected.
> However, when I run the query with tracing, I see that Cassandra still reads
> from ALL of the SSTables via {{collectAllData}} in {{CollationController}}.
> Given that this query only fetches a single column, I would expect this query
> to take the {{collectTimeOrderedData}} code path and then only examine the
> first SSTable after seeing that it contains the relevant data.
> Any insights on why this is the case and it what situations I would get the
> expected behaviour would be incredibly helpful!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)