Matt Byrd created CASSANDRA-21494:
-------------------------------------
Summary: Avoid deserializing and reserializing during
InMarker.toTerminals for applicable types
Key: CASSANDRA-21494
URL: https://issues.apache.org/jira/browse/CASSANDRA-21494
Project: Apache Cassandra
Issue Type: Improvement
Components: CQL/Interpreter
Reporter: Matt Byrd
Assignee: Matt Byrd
Attachments: Screenshot 2026-07-10 at 15.31.29.png, Screenshot
2026-07-10 at 15.32.08.png
We recently encountered an issue where the binding the elements of a large IN
query dominated the CPU utilisation.
This was in part a combination of anti-patterns:
1. The IN query had O (20k) entries
2. the client had set a very low paging size (50)
This was still with prepared statements in use.
This problem can be avoided by either increasing paging size or decreasing the
number of parameters in the IN clause and firing off separate queries in serial
or parallel.
However when analysing the allocation profile I noticed that
InMarker.toTerminals is taking input buffers from the client and essentially
deserializing and reserializing them before passing them on. (which seems to be
using a large portion of allocations in some of the attached allocation profile
screenshots)
For most types this is a no-op, granted for some deserialising and
reserializing them normalises them and some users or client libraries might be
subtly relying on this behaviour.
However for a lot of types and in particular the one in this stack-trace
(string) this is essentially a no-op.
I had a look/think about whether copying these buffers has some sort of subtle
positive side effect (e.g allowing us to garbage collect/process the old ones
in some way).
Some agent back and forth convinced me that the buffers allocated on the heap
and referenced through QueryOptions live as long as the buffers created since
all these things are stack local to query execution.
One relatively simple fix, is just to avoid doing this and retain just the
validation aspect, we probably do have to only apply this where the roundtrip
is provably the same bytes to avoid causing any kind of subtle
corruption/correctness problems with weird clients.
However a lot of every very important and useful types do round-trip back to
themselves identically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
