Summary
_compile_string_query's per-Plottable cache (keyed (language, query, params_key, node_dtypes_key)) hits normally on a plain graph, but appears to miss on every call for an indexed graph queried with index_policy="use".
Observation (master c355660 + #1738 tip, polars 1.42)
Counting actual compile_cypher_query invocations:
| setup |
compiles / 4 calls |
| plain graph, no policy kwarg |
1 (cache works) |
gfql_index_all() graph, no policy kwarg |
1 (cache works) |
200k/1M indexed graph + index_policy="use", same params |
11 / 11 calls |
same, varying $personId per call |
11 / 11 calls |
Expected: repeated identical (query, params) on the same Plottable should compile once.
Impact — measured as LOW, filing for correctness not urgency
The two loops above had effectively identical warm medians (11.07 ms vs 10.93 ms), so the wasted compile is not a measurable share of the wall at this size. This is filed so the cache's actual behavior is documented rather than assumed — the GFQL benchmark plan previously recorded "cache exists" as a reason to deprioritize compile work, and that assumption only holds for the non-index_policy path.
Suspected cause (unverified)
index_policy= likely rebinds the Plottable (fresh cache owner per call) — worth confirming before fixing, since the cache is attached with setattr on cache_owner.
Found while profiling the seeded-chain fast path for plans/gfql-benchmark-numbers.
Summary
_compile_string_query's per-Plottable cache (keyed(language, query, params_key, node_dtypes_key)) hits normally on a plain graph, but appears to miss on every call for an indexed graph queried withindex_policy="use".Observation (master c355660 + #1738 tip, polars 1.42)
Counting actual
compile_cypher_queryinvocations:gfql_index_all()graph, no policy kwargindex_policy="use", same params$personIdper callExpected: repeated identical
(query, params)on the same Plottable should compile once.Impact — measured as LOW, filing for correctness not urgency
The two loops above had effectively identical warm medians (11.07 ms vs 10.93 ms), so the wasted compile is not a measurable share of the wall at this size. This is filed so the cache's actual behavior is documented rather than assumed — the GFQL benchmark plan previously recorded "cache exists" as a reason to deprioritize compile work, and that assumption only holds for the non-
index_policypath.Suspected cause (unverified)
index_policy=likely rebinds the Plottable (fresh cache owner per call) — worth confirming before fixing, since the cache is attached withsetattroncache_owner.Found while profiling the seeded-chain fast path for plans/gfql-benchmark-numbers.