...

In some specific cases, users could want to influence the optimizer decision. Therefore, support for hints allowing the optimizer to use or ignore specific indexes will be added. 

Removing support for ALLOW FILTERING

Filtering is not inherently bad, and a query using filtering can, in some use cases, be more efficient  than one using another access pattern. Postgres, for example, seems to use indexes when the selectivity is roughly 5 to 10%(6). Unfortunately, without knowledge of the data distribution, and due to the distributed nature of Cassandra using filtering could result in terrible performance. To avoid that problem, the decision to use filtering was pushed to the user through ALLOW FILTERING.

As a cost based optimizer is aware of the current data distribution, it will nearly always be able to perform better work at selecting the most efficient access method than the user.

ALLOW FILTERING should, therefore, be deprecated.

To prevent the risk of running a too inefficient query, it will be possible to put a warning or hard limit on queries cost through guardrails.

New or Changed Public Interfaces

...

At the CQL level, the main changes will be removing some limitations and extending the places where some functionalities can be used. The most important changes will be around ALLOW FILTERING, as this expression will be ignored by the new Query Optimizer. The expression will still be supported at the parsing level to facilitate migration but will not affect the optimization outcome when the new optimizer is used.

Support for EXPLAIN and EXPLAIN ANALYZE will be added as well as support for hints.

...