Ok, overall I think the discussion has settled and the feature is
non-controversial, except the approach to ALLOW FILTERING.
I added a note to non goals saying that we don't want to change the
approach to ALLOW FILTERING here - and this proposal is to stay
consistent with the current approach.
We c
> It's easy for an inverted index to find matches efficiently, but not so easy
> for it to find non-matches.
Yes, I agree, it is not easy for an *index* to do that.
But I think at least in SAI we could do that by using the index to
find the matches, and, because they are always returned in the ro
It can be from not specifying the full primary key including clustering columns or it can be across multiple partitions. There are two scenarios. That’s why I created https://issues.apache.org/jira/browse/CASSANDRA-15803 and why I think it’s relevant for this. On Apr 14, 2023, at 9:37 AM, Lorina Po
Wow, you know, J.D., I've never actually heard ALLOW FILTERING described as
you did. Generally, the discussion is always in terms of
multiple partitions, probably because that is the situation in which the
memory is exceeded. Thanks for that definition.
Regardless of how this discussion goes, I'll
The documentation is wrong. ALLOW FILTERING has always meant that “rows will need to be materialized in memory and accepted or rejected by a column filter” aka the full primary key was not specified and some other column was specified. It has never been about multiple partitions.Basically “will th
Indeed requiring AF for "select * from ks.tb where p1 = 1 and c1 = 2 and
col2 = 1", where p1 and c1 are all the columns in the primary key, sounds
like a bug.
I think the criterion in the code is that we require AF if there is any
column restriction that cannot be processed by the primary key or a
On Thu, Apr 13, 2023 at 10:20 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> Somebody correct me if I am wrong but "partition key" itself is not enough
> (primary keys = partition keys + clustering columns). It will require ALLOW
> FILTERING when clustering columns are not specifie
.
From: Miklosovic, Stefan
Sent: Thursday, April 13, 2023 9:20
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-29 CQL NOT Operator
Somebody correct me if I am wrong but "partition key" itself is not enough
(primary keys = partition keys + clustering columns). It wi
ey (p1, c1));
select * from ks.tb where p1 = 1 and col1 = 2; // this will require allow
filtering
The documentation seems to omit this fact.
From: Henrik Ingo
Sent: Thursday, April 13, 2023 8:53
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-29 CQL NO
Wait... Why would anything require ALLOW FILTERING if the partition key is
defined? That seems to contradict documentation:
https://cassandra.apache.org/doc/latest/cassandra/cql/dml.html#allow-filtering
Also my intuition / expectation matches what the manual says.
henrik
On Fri, Apr 7, 2023 at 1
+1 to the proposal from a CQL perspective
*However*, whether we do this in the context of simple partition
restriction, a global index query, or a partition-restricted index query,
the NOT operator is most likely to be useful only in a post-filtering
capacity. (ex. WHERE indexed_set CONTAINS { 'fo
Considering all of the examples require using ALLOW FILTERING with the
partition key specified, I think it's appropriate to consider separating out
use of ALLOW FILTERING within a partition versus ALLOW FILTERING across the
whole table. A few years back we had a discussion about this in ASF sla
I love that this is finally coming to Cassandra. Absolutely hate that, once
again, we'll be endorsing the use of ALLOW FILTERING. This is an
anti-pattern that keeps getting legitimized.
Hot take: Should we just not do Milestones 1 and 2 and wait for an
index-only Milestone 3?
Patrick
On Thu, Apr
Overall I welcome this feature, was trying to use this around 1-2 months back
and found we didn’t support, so glad to see it coming!
From a testing point of view, I think we would want to have good fuzz testing
covering complex types (frozen/non-frozen collections, tuples, udt, etc.), and
rever
Hi everyone!
I created a new CEP for adding NOT support to the query language and
want to start discussion around it:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
Happy to get your feedback.
--
Piotr
15 matches
Mail list logo
