perf(gfql): resident-index gathers engage for property-seeded lookups (SF1-vs-Neo4j lane)#1770
Conversation
The index path required the seed filter on the node BINDING column; the LDBC/user pattern (synthetic key binding + MATCH on the id property) never engaged it (found via in-harness serve-spies: 0 serves at SF1). Decoupled: seed row scans by property when needed; CSR adjacency + node-id gathers engage regardless — binding-column values are the key domain however the seed was found. Pinned rebound-key engagement+parity test (pandas+polars). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6dQEcjdazEnzuvuwf73ZL
|
dgx SF1 re-measure (full cypherbase-polars suite on this branch, same-day-comparable vs
SF1-vs-Neo4j scoreboard: 4 GFQL wins / 1 Neo4j win (was 3/2). No regressions across the other 15 suite rows (all within noise or better). The remaining loss + the two ~100ms wins ride 🤖 Generated with Claude Code |
|
X-platform bench-regression validation (dgx RAPIDS container, GPU lanes live): 544 tests pass incl. cuDF + polars-gpu fast-path/index/hop suites; GFQL_PERF_TESTS=1 wall-clock gate passes (indexed ≥1.5× scan @500k edges). Protocol note: this container run is the standing x-platform gate for seeded-fast-path PRs — CI covers py3.8-3.14 × pandas2/3 × polars; the GPU lanes only exist here. 🤖 Generated with Claude Code |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6dQEcjdazEnzuvuwf73ZL
New docs/source/gfql/indexing.rst: lifecycle guide to GFQL resident indexes (gfql_index_all / gfql_index_edges / create_index / show_indexes / drop_index) — node-id + CSR in/out adjacency sidecars, what engages them on 0.58.0 (seeded typed-hop fast paths incl. property RETURNs and property-seeded lookups per graphistry#1768/graphistry#1770, direct g.hop(); general polars chain traversal honestly noted as not yet covered), the identity + fingerprint staleness contract with safe declines, engine notes (polars needs gfql_index_all(engine='polars') until graphistry#1767), 0.58.0-tag measured numbers, and a runnable end-to-end example (executed). Wired into the GFQL toctree + recommended paths next to index_adjacency; CHANGELOG entry under Development > Documentation. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6dQEcjdazEnzuvuwf73ZL
1 participant
Problem (found via in-harness serve-spies on the SF1 suite, master bffdc34)
The #1768 resident-index acceleration required the seed filter to hit the node BINDING column (
node in n0f). The SNB harness — and the general user pattern — binds a synthetic key (__pgbench_node_key__) whileMATCH (m {id: $x})filters theidPROPERTY, so the index path posted 0 serves across the entire SF1 suite: message-creator ran its 39ms scan branch despite valid resident indexes.Fix
Decouple the gates in all three seeded helpers: the seed row falls back to the property scan when the binding column isn't in the filter, but the CSR adjacency frontier gather and node-id candidate gathers engage whenever valid indexes are resident — their inputs are binding-column values (the index key domain) no matter how the seed rows were found. Decline contract otherwise unchanged (stale/absent index, non-numeric id families).
Verification
test_property_seeded_engages_adjacency_index: rebound-key graph (binding ≠ filter column), adjacency-serve asserted + parity vs un-indexed, pandas + polars.🤖 Generated with Claude Code
https://claude.ai/code/session_01Y6dQEcjdazEnzuvuwf73ZL