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 applications to have performant and 
effective queries but it kinds of loses the applicability for virtual tables 
when it literally holds just handful of entries in memory and it just does not 
matter, does it?

What do you think about implicitly allowing filtering for virtual tables so we 
save ourselves from these pesky errors when we want to query arbitrary column 
and we need to satisfy CQL spec just to do that?

It is not like we would promote bad habits because virtual tables are meant to 
be queried by operators / administrators only.

We can also explicitly document this behavior.

Among other options, we may try to implement secondary indices on virtual 
tables but I am not completely sure this is what we want because its complexity 
etc. Is it even necessary to put such complex logic in place just to be able to 
select any column on few entries in memory?

I put together a draft here (1). It would be ever possible to implicitly allow 
filtering on virtual tables only and it would be implementator's responsibility 
to decide that, per table.

For all virtual tables we currently have, I would enable this everywhere. I do 
not think there is any virtual table where we would not want to enable it or 
where people HAVE TO specify that.

(1) https://github.com/apache/cassandra/pull/2131

Reply via email to