Question & Answer
Question
In open source Cassandra, the debug.log slow queries appear with ALLOW FILTERING at the end, for example:
DEBUG [ScheduledTasks:1] 2026-03-25 14:10:30,190 MonitoringTask.java:175 - 1 operations were slow in the last 5003 msecs:
<SELECT column_a, column_b FROM keyspace.table WHERE column_a = 1a878e2g-sf2b-4c5b-8507-d73148ca27c8 ALLOW FILTERING>, was slow 5 times: avg/min/max 606/575/636 msec - slow timeout 500 msec/cross-nodeHowever, the queries listed were not run with ALLOW FILTERING by the client.
Why does ALLOW FILTERING appear in the debug.log even though it was not part of the query?
Answer
In open source Cassandra 4.1 and above, the CQL statement printed in the log for slow queries is designed to always be valid. A decision as part of that design is to always add ALLOW FILTERING to the end of the query.
This change can be seen in CASSANDRA-16510
A quote from that Jira item:
"The trickiest part is ALLOW FILTERING, since it's not easy to determine whether a command strictly needs filtering. This check is done during parsing, and the concept doesn't exist internally. For that I have just changed the implementations of toCQLString to simply always add ALLOW FILTERING. This is not ideal but IMO it's correct and consistent with the idea that filtering is always allowed internally."
Therefore, it is expected for ALLOW FILTERING to always appear in the debug.log slow queries.
It does not indicate that the query was run with that option used. There can be concern about potential latency impacts when ALLOW FILTERING is used in the query, as discussed in Cassandra documentation.
Was this topic helpful?
Document Information
Modified date:
26 March 2026
UID
ibm17267480