Yeshchenko
Sent: Monday, February 6, 2023 12:11
To: dev@cassandra.apache.org
Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe
uot;ALLOW FILTERING" clause to every
>> SELECT statement (to virtual tables only?) a user submits. I am not sure if
>> this is doable yet though.
>>
>>
>> From: David Capwell > <mailto:dcapw...@apple.com><mailt
ould not be a big deal for operators to
> set. We would have to make sure to add "ALLOW FILTERING" clause to every
> SELECT statement (to virtual tables only?) a user submits. I am not sure if
> this is doable yet though.
>
> ________
> Fr
: Josh McKenzie
Sent: Friday, February 3, 2023 23:39
To: dev
Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
they would
David Capwell
> Sent: Friday, February 3, 2023 22:42
> To: dev
> Cc: Maxim Muzafarov
> Subject: Re: Implicitly enabling ALLOW FILTERING on virtual tables
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the se
ause to every SELECT
statement (to virtual tables only?) a user submits. I am not sure if this is
doable yet though.
From: David Capwell
Sent: Friday, February 3, 2023 22:42
To: dev
Cc: Maxim Muzafarov
Subject: Re: Implicitly enabling ALLOW FILTERING on vi
> I don't think the assumption that "virtual tables will always be small and
> always fit in memory" is a safe one.
Agree, there is a repair ticket to have the coordinating node do network
queries to peers to resolve the table (rather than operator querying
everything, allow the coordinator
ALLOW FILTERING on virtual tables
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Why not introduce a general table option that toggles ALLOW FILTERING behaviour
and just flip
Why not introduce a general table option that toggles ALLOW FILTERING behaviour and just flip it for virtual tables we want this behaviour for? Users can do it too, for their own tables for which it’s suitable.On 3 Feb 2023, at 20:59, Andrés de la Peña wrote:For those eventual big virtual tables
Yes, I am not -1. Just that if we do it we should be ok in the future with
some virtual tables that did not have this behavior. Should consider if
this would be confusing. Really should be ok imho since they just would get
the "need allow filtering" error on said future tables.
Chris
On Fri, Feb
For those eventual big virtual tables there is the mentioned flag
indicating whether the table allows filtering without AF.
I guess the question is how can a user know whether a certain virtual table
is one of the big ones. That could be specified in the doc for each table,
and it could also be
Just to 2nd what Scott days. While everything is in memory now, it may not
be in the future, and if we add it implicitly, we are tying ourselves to be
in memory only. However, I wouldn't -1 the idea.
Another option may be a cqlsh option (ie like expand on/off) to always
include a flag so it
There are some ideas that development community members have kicked around that may falsify the assumption that "virtual tables are
tiny and will fit in memory."One example is CASSANDRA-14629: Abstract Virtual Table for very large result
Hello Stefan,
Regarding the decision to implicitly enable ALLOW FILTERING for
virtual tables, which also makes sense to me, it may be necessary to
consider changing the clustering columns in the virtual table metadata
to regular columns as well. The reasons are the same as mentioned
earlier: the
I think removing the need for ALLOW FILTERING on virtual tables makes sense
and would be quite useful for operators.
That guard exists for performance issues that shouldn't occur on virtual
tables. We also have a flag in case some future virtual table
implementation has limitations regarding
Hi list,
the content of virtual tables is held in memory (and / or is fetched every time
upon request). While doing queries against such table for a column outside of
primary key, normally, users are required to specify ALLOW FILTERING. This
makes total sense for "ordinary tables" for
16 matches
Mail list logo
