gregfelice commented on issue #2349: URL: https://github.com/apache/age/issues/2349#issuecomment-4281629375
@jrgemignani — thank you for the thorough analysis. You're right on the substance, and I was wrong on several points. Three corrections accepted: 1. **Cycle prevention exists.** `edge_state_entry.used_in_path` + `is_edge_in_path()` enforce edge-uniqueness on every DFS step. I mischaracterized this as "no cycle detection" when it's actually edge-isomorphism per the openCypher spec. 2. **A visited-node set would break semantics.** Swapping edge-isomorphism for vertex-isomorphism would silently drop valid paths and violate the spec. Not the right fix. 3. **The benchmark is apples-to-oranges.** Full path enumeration vs. deduplicated reachability answer different questions; the runtime delta reflects cardinality, not a bug. That leaves one narrower concern from the original issue that I'd like to keep on the table, framed correctly this time: **Unbounded VLE (`[*]`, `[*1..]`) has no safety cap.** With `uidx_infinite = true`, termination relies solely on edge-uniqueness depletion, so worst case on a dense graph is O(|E|!). This is inherent to edge-unique path enumeration — not fixable by algorithm change — but it is a foot-gun with no guard rail. Two concrete, non-invasive improvements: - **A GUC (e.g. `age.vle_max_depth`, default unlimited or a large sentinel)** that errors out when an unbounded traversal exceeds the cap. Opt-in safety for production workloads without changing semantics for anyone who doesn't set it. - **Doc note in the VLE / variable-length relationship section** clarifying edge-isomorphism vs. vertex-isomorphism and the unbounded-depth cost model, so future users don't file the same misdiagnosis I did. The "BFS-backed reachability / shortestPath" angle you mentioned lives in #2350 — happy to treat that as the separate work item it really is. If the narrowed scope (GUC + docs) is agreeable I'll retitle this issue accordingly and submit a PR. Otherwise happy to close and re-file. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
