[
https://issues.apache.org/jira/browse/CASSANDRA-11031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270470#comment-15270470
]
ZhaoYang edited comment on CASSANDRA-11031 at 5/5/16 10:16 AM:
---------------------------------------------------------------
[~slebresne] Thank you. I think the performance will be better than `allow
filtering on clustering key`, is it?
> we can support allow filtering on Partition Key, as far as I know, Partition
> Key is in memory.
I think I was wrong about the implementation. I thought that all partition key
are in offheap memory and c* could it before fetching columns.
> as this is a new feature and a pretty minor one imo for the reason discussed
> above, it should really only go to trunk at this point. This will change the
> patch substantially.
I will make PR based on 3.x
> even if we support filtering on missing partition key, I really don't see a
> reason to special case it only for the first one. The code should be more
> generic than this.
How about only equal condition?
> we'd obviously need the patch to have some testing coverage to consider it.
sure. dtest: https://github.com/riptano/cassandra-dtest/pull/969/files
was (Author: jasonstack):
[~slebresne] Thank you. I think the performance will be better than `allow
filtering on clustering key`, is it?
> we can support allow filtering on Partition Key, as far as I know, Partition
> Key is in memory.
I think I was wrong about the implementation. I thought that all partition key
are in offheap memory and c* could it before fetching columns.
> as this is a new feature and a pretty minor one imo for the reason discussed
> above, it should really only go to trunk at this point. This will change the
> patch substantially.
I will make PR based on 3.x
> even if we support filtering on missing partition key, I really don't see a
> reason to special case it only for the first one. The code should be more
> generic than this.
How about only equal condition?
> we'd obviously need the patch to have some testing coverage to consider it.
sure. I will add to c*-dtest?
> MultiTenant : support “ALLOW FILTERING" for First Partition Key
> ---------------------------------------------------------------
>
> Key: CASSANDRA-11031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11031
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL
> Reporter: ZhaoYang
> Assignee: ZhaoYang
> Priority: Minor
> Fix For: 3.x
>
> Attachments: CASSANDRA-11031-3.7
>
>
> Currently, Allow Filtering only works for secondary Index column or
> clustering columns. And it's slow, because Cassandra will read all data from
> SSTABLE from hard-disk to memory to filter.
> But we can support allow filtering on Partition Key, as far as I know,
> Partition Key is in memory, so we can easily filter them, and then read
> required data from SSTable.
> This will similar to "Select * from table" which scan through entire cluster.
> CREATE TABLE multi_tenant_table (
> tenant_id text,
> pk2 text,
> c1 text,
> c2 text,
> v1 text,
> v2 text,
> PRIMARY KEY ((tenant_id,pk2),c1,c2)
> ) ;
> Select * from multi_tenant_table where tenant_id = "datastax" allow filtering;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
