CASSANDRA-15241 Add a virtual table that exposes currently running queries #1704

maedhroz · 2022-06-27T23:42:23Z

No description provided.

maedhroz · 2022-06-27T23:42:45Z

https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-15241-trunk-v2&filter=all

maedhroz · 2022-06-27T23:44:39Z

src/java/org/apache/cassandra/concurrent/SEPWorker.java

@clohfink Without setting the task here, it's possible to miss tasks, right?

maedhroz · 2022-06-27T23:45:54Z

src/java/org/apache/cassandra/concurrent/TaskFactory.java

Before the simulator changes, this bit wouldn't have been necessary, as everything got wrapped up in FutureTask. Is there a better way?

CC @belliottsmith

It's similar to what we still do w/ FutureTask for NTR stage requests (and did for everything in the old patch).

src/java/org/apache/cassandra/db/virtual/QueriesTable.java

src/java/org/apache/cassandra/service/StorageProxy.java

src/java/org/apache/cassandra/transport/Dispatcher.java

src/java/org/apache/cassandra/service/StorageProxy.java

src/java/org/apache/cassandra/transport/Dispatcher.java

src/java/org/apache/cassandra/concurrent/FutureTask.java

src/java/org/apache/cassandra/db/virtual/QueriesTable.java

frankgh · 2022-06-28T20:19:42Z

src/java/org/apache/cassandra/db/virtual/QueriesTable.java

I'm curious about the micros resolution. Would nanos suffice? Maybe there's a good motivation for micros

This I copied from @clohfink 's original patch. I think most of the other metrics we expose around latencies/running times are in micros.

patch by Chris Lohfink; reviewed by Caleb Rackliffe and Benedict Elliott Smith for CASSANDRA-15241 Co-authored-by: Chris Lohfink <clohfink@apple.com> Co-authored-by: Caleb Rackliffe <calebrackliffe@gmail.com> Co-authored-by: Benedict Elliott Smith <benedict@apache.org>

maedhroz · 2022-07-08T21:16:59Z

Committed as 89f3978

### What is the issue Fixes riptano/cndb#13822 CNDB test pr riptano/cndb#13826 ### What does this PR fix and why was it fixed SAI’s DiskANN/JVector engine currently **always searches with pruning enabled**, trading recall for latency. That is fine for most workloads, but: * **Threshold / bounded ANN queries** can lose matches when pruning exits early. * Performance‑testing users need an easy way to turn pruning off to measure the recall/latency curve. This patch introduces a per‑query **`use_pruning`** option so users and operators can choose the trade‑off that suits them. --- #### New query option ```cql WITH ann_options = {'use_pruning': true|false} ``` *When omitted we fall back to the node level default (see below).* #### Default behaviour * Cluster‑wide default is controlled by the JVM system property: ``` -Dcassandra.sai.jvector.use_pruning_default=<true|false> ``` exposed as `V3OnDiskFormat.JVECTOR_USE_PRUNING_DEFAULT`. * The property defaults to `true`, preserving existing behaviour. #### Validation rules * Value must be the literal `true` or `false` (case‑insensitive). * Unknown ANN option keys continue to raise `InvalidRequestException`. #### Usage * `Orderer` computes the value of the `usePruning` option by using the `use_pruning` value if it is not null or the jvm default if it is null and passes it down to **all** `graph.search()` calls. * Threshold / bounded ANN queries always pass `use_pruning = false` because correctness > latency for those paths (this is a net new change, but it's very minor and might not have any impact on those queries depending on the jvector implementation) #### Compatibility * We added one flag bit to `ANNOptions` serialization; older nodes ignore unknown bits, so mixed‑version clusters are fine (though they do throw an exception for unknown settings) #### Tests added / updated * Parsing, validation and transport round‑trips (`ANNOptionsTest`). * Distributed smoke (`ANNOptionsDistributedTest`). * Recall regression for pruning vs no‑pruning (`VectorSiftSmallTest.ensureDisablingPruningIncreasesRecall`).

### What is the issue Documents the following PRs: apache#1676, apache#1704, apache#1705

Fixes riptano/cndb#13822 CNDB test pr riptano/cndb#13826 SAI’s DiskANN/JVector engine currently **always searches with pruning enabled**, trading recall for latency. That is fine for most workloads, but: * **Threshold / bounded ANN queries** can lose matches when pruning exits early. * Performance‑testing users need an easy way to turn pruning off to measure the recall/latency curve. This patch introduces a per‑query **`use_pruning`** option so users and operators can choose the trade‑off that suits them. --- ```cql WITH ann_options = {'use_pruning': true|false} ``` *When omitted we fall back to the node level default (see below).* * Cluster‑wide default is controlled by the JVM system property: ``` -Dcassandra.sai.jvector.use_pruning_default=<true|false> ``` exposed as `V3OnDiskFormat.JVECTOR_USE_PRUNING_DEFAULT`. * The property defaults to `true`, preserving existing behaviour. * Value must be the literal `true` or `false` (case‑insensitive). * Unknown ANN option keys continue to raise `InvalidRequestException`. * `Orderer` computes the value of the `usePruning` option by using the `use_pruning` value if it is not null or the jvm default if it is null and passes it down to **all** `graph.search()` calls. * Threshold / bounded ANN queries always pass `use_pruning = false` because correctness > latency for those paths (this is a net new change, but it's very minor and might not have any impact on those queries depending on the jvector implementation) * We added one flag bit to `ANNOptions` serialization; older nodes ignore unknown bits, so mixed‑version clusters are fine (though they do throw an exception for unknown settings) * Parsing, validation and transport round‑trips (`ANNOptionsTest`). * Distributed smoke (`ANNOptionsDistributedTest`). * Recall regression for pruning vs no‑pruning (`VectorSiftSmallTest.ensureDisablingPruningIncreasesRecall`).

### What is the issue Documents the following PRs: apache#1676, apache#1704, apache#1705