mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-10-26 06:43:15 +08:00
Martin Vogel
312fb36844
Three query rewrites over the existing indexes; every MCP response stays
byte-identical to c9cacdf0 (tools + Cypher suites on django, redis and the
linux kernel, same index each).
- arch_packages: GROUP BY +n.name. With a bare column the planner walked
idx_nodes_name over every node to get groups in name order, with a table
lookup per node to test the label (6.3 s of the 7.3 s get_architecture on
the 8.5M-node kernel graph, for 5 Package nodes). The unary plus seeks
idx_nodes_label instead; the name tie-break is explicit because a sorted
GROUP BY follows the ORDER BY direction and reversed tied counts.
- get_schema_impl: label / edge-type counts step through the distinct values
(MIN(col) > previous) and count each value's index range instead of a
GROUP BY scan: kernel 0.26 -> 0.16 s and 0.54 -> 0.32 s. Values reach
ORDER BY in the same ascending order, so ties keep their order.
- cbm_store_search: an anchored name_pattern ("^schedule$", "^kmalloc")
adds idx_nodes_name ranges for its literal prefix (every ASCII letter case
of the first three letters under iregexp, which runs in the C locale),
one UNION ALL arm per range merged by ORDER BY name, id without a sort;
the count sums the ranges. LIKE hints and the regex stay in the WHERE, so
the rows are those of the plain scan. Patterns that do not compile keep
the plain query (and its error).
Kernel, interleaved medians n=5: get_architecture 9.2-10.3 s -> 1.03 s,
get_graph_schema 0.76 s -> 0.48 s, cycles 2.24 s -> 2.04 s, search_graph
^schedule$ 1.15 s -> 14 ms, ^kmalloc + label 0.64 s -> 14 ms. Peak daemon
RSS for get_architecture +67 MB -> +22 MB.
The ranged SQL is built with a bounds-checked append (no snprintf-derived sizes) into CBM_MEM_CLASS_STORE buffers; a build that does not fit rolls its binds back and the plain query runs.
Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>