Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

PathDB: A system for evaluating regular path queries

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read PathDB claims that regular path queries can be evaluated as compositions of algebraic operators over multisets of paths, outperforming automaton-guided DFS and BFS traversal on large property graphs, often by more than an order of…

desk verdict A useful system paper with a real algebraic contribution, but the headline performance claim is not supported by its own Table 4. read the letter →

arxiv 2507.01755 v3 pith:HIR6YXHL submitted 2025-07-02 cs.DB

Roberto García , Renzo Angles , Vicente Rojas , Sebastián Ferrada This is my paper
classification cs.DB MSC 68P1568R10
keywords regularpathqueriesalgebrarecursivejoinpropertygraphsrestrictorswalksemanticstrailqueryevaluation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

PathDB aims to show that regular path queries (RPQs), the standard mechanism for recursive reachability in graph databases, can be evaluated as compositions of algebraic operators over multisets of full paths instead of by graph traversal. The paper proposes a closed path algebra with five operators, including a recursive join, and a declarative language inspired by the emerging graph-query standard; every query compiles into an operator tree and runs through iterator-based physical plans. On four synthetic social-network property graphs and a workload of 142 queries derived from 26 path patterns, the experimental evaluation reports that PathDB outperforms two automaton-guided traversal baselines (DFS and BFS), often by more than an order of magnitude. If the claim is right, graph database engines can return full paths under walk, trail, simple, and acyclic semantics without relying on traversal-based enumeration.

What carries the argument

The carrying object is the recursive join $\phi_\tau(S)$, the least fixed point of repeatedly joining the accumulated path multiset with the base path multiset, using the join operator $S \bowtie_\tau S'$ that concatenates two linkable paths (the end node of one equals the start node of the other) while enforcing restrictor $\tau$. Selection $\sigma_c$ filters paths on node/edge labels, properties, length, and trail/simple/acyclic tests; union is bag union; projection $\pi^j_\alpha$ turns the first $j$ paths into a relational table. The algebra is closed in that every operator except projection returns a multiset of paths, which lets one operator's output feed another and lets intermediate results be reused. Restrictors also govern termination: Walk allows infinite path sets on cyclic graphs, while Trail, Simple, and Acyclic bound recursion by forbidding repeated edges or nodes.

What would settle it

Run the same 142-query workload with a 100-path limit and a 120-second timeout on the same four graphs using an independent, optimized traversal-based engine that supports the same four path restrictors: if its median execution times matched or beat PathDB's, the paper's claim that the algebraic strategy itself is the source of the speedup would fail.

Watch

Extended reading notes

Core claim

The central claim is that path queries gain a practical advantage when intermediate results are first-class multisets of paths: each operator consumes one or two such multisets and returns another, so recursive construction reuses shared subpaths instead of re-exploring them. The recursive join operator builds longer paths by concatenating linkable paths and repeating to a fixed point, while a path restrictor filters the growing multiset at each step. PathDB compiles a declarative RPQ into a tree of selection, join, union, recursive join, and projection operators, and executes the tree with lazy iterators. In the first experiment, on graphs with up to about 3.2 million nodes and 17.3 million edges, PathDB's slowest query took roughly 7 seconds, while the DFS baseline's slowest took about 49 seconds and BFS about 88 seconds, with PathDB leading on every abstract pattern.

Load-bearing premise

The load-bearing premise is that the two self-implemented automaton-guided traversal baselines, DFS+A and BFS+A, fairly represent standard traversal-based RPQ evaluation; Section 6.5 of the paper admits that implementation choices (data structures, caching, object allocation) may still influence their performance.

Editorial extensions

If this is right

  • Full-path results become available under all four restrictors (walk, trail, simple, acyclic) from a single engine, rather than only endpoint pairs as in most traversal-based RPQ evaluation.
  • Recursive queries are where the algebraic strategy shows the largest advantage: on the 1.0-scale graph the slowest PathDB query took about 7 seconds versus about 49 seconds for the DFS baseline and 88 seconds for the BFS baseline.
  • Because plans are operator trees over path multisets, classical relational optimizations such as predicate pushdown and operator reordering become applicable to path queries.
  • The cost of a query tracks the syntactic complexity of its regular expression, and patterns with closure over concatenation ((A·B)+, (A·B)*) are the expensive ones across all four semantics.
  • All four path semantics are computable in practical times on the tested 9.3-million-node graph, with Walk often fastest and Simple or Acyclic generally the most expensive.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next experiment the paper leaves implicit is a head-to-head comparison against an independently implemented, optimized traversal engine on the same workload; the current evidence isolates the evaluation strategy only relative to the two self-built baselines.
  • The recursive join operator is the clear performance lever: investing in lazy evaluation, incremental materialization, or early cycle-pruning should directly reduce the high times seen for closure-over-concatenation patterns.
  • The algebra's closure suggests a planner could automatically choose the cheapest sound restrictor for a given query, since Walk recursion can diverge on cyclic graphs while Trail, Simple, and Acyclic terminate by construction.
  • Extending the operators to spill intermediate path multisets to disk or to evaluate multi-pattern and aggregate path queries are natural next steps that the operator-at-a-time design seems able to host without changing the algebra's semantics.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents PathDB, an in-memory Java engine that evaluates regular path queries over property graphs using a closed path algebra over multisets of paths. The algebra comprises selection, join, union, recursive join, and projection, with support for walk, trail, simple, and acyclic path restrictors. Declarative GQL-inspired queries are translated into operator trees and executed via iterators. The experimental section compares PathDB against two self-implemented automaton-guided traversal baselines (DFS+A and BFS+A) on LDBC SNB graphs G1--G3 under Trail semantics, and separately measures PathDB alone on G4 under all four restrictors. The paper claims PathDB consistently outperforms both baselines, often by more than an order of magnitude.

Significance. If the claims are correct, the paper makes a useful contribution: it demonstrates that an algebra-based, operator-at-a-time strategy can evaluate full-path RPQs with multiple path semantics, and it provides a concrete system with publicly available code and workloads. The idea of reusing intermediate path multisets instead of repeatedly traversing overlapping subpaths is principled and plausibly beneficial, especially for recursive patterns. The paper also explicitly discusses threats to validity and publishes reproducibility artifacts, which raises the evidentiary quality. However, the significance is tempered by two issues: the central performance claim is not as cleanly supported as stated, and the formal development has gaps in the definition of projection and in the specification of the translation from queries to algebra.

major comments (4)
  1. [Table 4; Abstract; Section 6.4.1; Section 8] The claim that PathDB 'consistently outperforms' both baselines is contradicted by Table 4 on graph G3 (SF 1.0) for abstract pattern ((A·B)·C): PathDB averages 4.027 s while BFS+A averages 3.918 s. This is not an aggregate anomaly, since the same row in the G3 block also shows BFS+A's minimum time (3.918 s). The abstract, Section 6.4.1, and Section 8 all make unqualified consistency claims. The authors should either correct the data, show that this entry is an outlier caused by a specific real-query instance, or qualify the claim (e.g., 'PathDB is faster on almost all patterns, with one exception').
  2. [Section 4.2, Projection operator] The definition of projection π_j^α(S) = {proy(α, p_i) | 1 ≤ i ≤ min(j,|S|)} refers to 'the i-th path in S', but S is a multiset and the algebra never defines an ordering over the paths in a multiset. Since the LIMIT clause in the query language (Section 5.1) depends on this projection, the semantics of LIMIT and the meaning of 'first j paths' are under-specified. The authors need to define an explicit order (e.g., by path construction order, by a total order on path identifiers, or by a nondeterministic but fixed operator implementation) or redefine projection so that it does not depend on an unspecified ordering.
  3. [Section 5.2] The translation functions T_M, T_W, and T_R, which map MATCH, WHERE, and RETURN clauses to algebra expressions, are only presented through a single running example. The paper states that 'for the sake of space' the detailed description is omitted, but this translation is a core contribution: it is the mechanism that connects the declarative language to the algebraic evaluation. Without a precise recursive definition of T_M (covering alternation, Kleene star, optionality, concatenation, and negation) and a correctness argument, the reader cannot verify that the system indeed evaluates RPQs according to the stated algebra. This is a load-bearing gap and should be addressed by giving the full translation rules, at least in an appendix.
  4. [Section 6.2; Section 6.4.1; Section 6.5] The performance comparison uses only two baselines (DFS+A and BFS+A) that were implemented by the same authors for this paper. As Section 6.5 admits, implementation choices such as data structures, caching, and object allocation may influence the results. The paper does not benchmark against any existing graph database system or an established product-graph implementation, so the evidence supports the claim only with respect to these two particular implementations, not to 'traversal-based evaluation' as a general approach. Furthermore, the main experiment is restricted to the Trail restrictor (Section 6.4.1), while the abstract and conclusions present the outperformance claim without this qualification. The authors should either add a third-party comparison or clearly limit the headline claim to the tested baselines and Trail semantics.
minor comments (5)
  1. [Appendix A (grammar)] The restrictor token for acyclic is written as 'ACYCLIC’' with a closing quotation mark instead of an ASCII apostrophe; this is a typo in the grammar definition.
  2. [Section 6.4.2] The text states that 'adding an additional concatenation increases the time to 1.269 seconds' when discussing the (A·B) pattern, whose Table 5 value is 1.436 seconds for Walk; 1.269 seconds is actually the value for ((A|B)|C). The sentence should refer to the correct pattern or be rephrased.
  3. [Section 6.4.2] The text says 'Acyclic shows the longest time with 36.511 seconds for (A·B)+', but Table 5 shows the Acyclic maximum is 36.551 seconds for (A·B+), and the value for (A·B)+ is 20.200 seconds. The reported pattern and value do not match the table.
  4. [Section 4.2, recursive join and join] The definitions of join and recursive join use set-builder notation (e.g., {p1∘p2 | ...}) without specifying how multiplicities are handled when the input is a multiset. Since the paper emphasizes a closed algebra over multisets, the operator definitions should clarify the multiplicity semantics (e.g., that duplicates are preserved according to the Cartesian product of occurrences).
  5. [Section 6.3.2] The real-query example 'MATCH TRAIL p = (x)-[(likes.hasCreator)*]-(y)...' uses a Kleene star, while the corresponding abstract pattern in Table 3 is (A·B)+ (transitive closure) for the template (likes.hasCreator)+. The example appears to be for a different pattern; consider aligning it with the table or explicitly noting that it illustrates a star query.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: PathDB's algebraic derivation is self-contained; only minor self-citations appear in non-load-bearing roles.

full rationale

PathDB's central contribution is a closed path algebra whose operators (selection, join, union, recursive join, projection) are defined in Section 4 independently of the experimental outcomes, and the RPQ-to-algebra translation in Section 5.2 is a direct syntax-directed mapping rather than a fitted or self-referential derivation. The performance comparison in Section 6 compares PathDB to two self-implemented traversal baselines, with Section 6.5 explicitly acknowledging that 'implementation choices... may still influence performance'; this is a construct-validity limitation, not a circular step, because the baselines' behavior is not derived from PathDB's equations and no parameter of PathDB is fitted to the baselines' outputs. The only identifiable self-citations are [10] (PGDF, used as an input file format in Section 2.3) and the co-authored survey [3]; neither carries a load-bearing argument, and the paper does not lean on a uniqueness theorem or prior work by its authors to force its design. The apparent inconsistency in Table 4 for ((A·B)·C) on G3, where PathDB (4.027 s) is slower than BFS+A (3.918 s), undermines the 'consistently outperforms' phrasing in Section 6.4.1 and the abstract, but contradiction with a table entry is a factual/correctness issue rather than circularity. Overall, there is no step in the paper that reduces, by its own equations or definitions, to its own inputs.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the standard property-graph model, GQL-style restrictor semantics, termination of recursive evaluation, and an unprovided query-to-algebra translation. The experimental parameters (100-path limit, 120-second timeout, median-out-degree source selection) are hand-chosen and affect the reported runtimes. No fitted constants are used in the algebra itself.

free parameters (3)
  • Result limit = 100 paths
    Section 6.3.3 caps query results at 100 paths to control memory; this limit affects execution times for recursive queries and interacts with lazy vs materialized evaluation.
  • Query timeout = 120 seconds
    Section 6.3.3 uses a 120-second timeout; queries that exceed it are recorded as T/O, which changes aggregate averages and max values.
  • Source-node selection = median out-degree node
    Section 6.3.2 instantiates each template query with a source node whose out-degree for the adjacent label is the median; this choice controls path multiplicity and recursion depth and is a hand-selected experimental parameter.
assumptions (4)
  • domain assumption Property graph model G=(N,E,rho,lambda,nu) as defined in Section 3.1
    PathDB and the path algebra operate on this graph model; it is a standard definition but is assumed rather than derived.
  • domain assumption Path restrictor semantics for Walk, Trail, Acyclic, and Simple follow GQL (Section 4.1.2)
    The correctness of the restrictor checks rests on adopting these standard semantics unchanged.
  • domain assumption Recursive join reaches a fixed point for Trail, Acyclic, and Simple restrictors (Section 4.2)
    The paper notes Walk may diverge on cyclic graphs and relies on the other restrictors for termination, but provides no proof of fixed-point convergence.
  • ad hoc to paper The translation functions T_M, T_W, T_R from path queries to algebra expressions exist and are correct (Section 5.2)
    The paper states these functions without defining them, so the compilation of regular expressions into algebraic plans is an unverified premise.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PathDB: A system for evaluating regular path queries." pith.science (2026). https://pith.science/paper/HIR6YXHL

@misc{pith2026250701755,
  author       = {Pith},
  title        = {Pith review of: PathDB: A system for evaluating regular path queries},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HIR6YXHL}},
  note         = {Machine review of arXiv:2507.01755}
}
read the original abstract

Regular Path Queries (RPQs) are a core mechanism for expressing recursion and reachability in graph databases. However, most systems evaluate RPQs with traversal-based algorithms that repeatedly explore overlapping subpaths and offer limited control over path semantics. We present PathDB, an algebraic query engine for RPQs based on a closed path algebra over multisets of paths with five operators: selection, join, union, recursive join, and projection. PathDB provides (i) a GQL-inspired declarative language that supports RPQs with multiple semantics (walk, trail, simple, and acyclic), (ii) an operator-at-a-time execution procedure analogous to relational query processing, and (iii) result formats that include full paths, not only endpoint pairs. The experimental evaluation, based on four LDBC Social Network Benchmark property graphs and a workload of 142 queries derived from 26 path patterns, showed that PathDB outperforms two automaton-guided traversal baselines (DFS and BFS), often by more than an order of magnitude.

Figures

Figures reproduced from arXiv: 2507.01755 by the authors.

Figure 1
Figure 1. PathDB architecture. The parser takes a query expressed in PathDB’s GQL-inspired language and produces an ab￾stract syntax tree (AST). The logical plan manager then transforms the AST into a logical plan 3 [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Graphical representation of a property graph modeling a social network. 5. ν : (N ∪ E) × L ⇀ V is a partial function that defines properties for nodes and edges. Given an edge e ∈ E, if ρ(e) = (n1, n2) then n1 is the source of e and n2 is its target. If ν(o, l) = v, then the object o (node or edge) has property l with value v. Given a property graph G = (N , E, ρ, λ, ν), a path p in G is a sequence [n1, e1, n2, e2, … view at source ↗
Figure 3
Figure 3. Hash-based index for node storage. Each entry contains a node identifier as key, and the value is a reference to the corresponding node object. Key Value knows likes hasCreator null null null id:e1, label:knows, src:n1, tgt:n2 [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Hash-based index for edge storage. Each entry contains an edge label as key, and the value is a reference to a linked list of edges having that label. Each element of the linked list contains either a reference to an edge object or null to indicate the end of the linke…
Figure 5
Figure 5. Figure 5: Example of a PathDB declarative path query. 5 Declarative Query Language This section introduces the query language used in PathDB to express regular path queries declara￾tively. Specifically, we describe the syntax of the language and the method for translating declar…
Figure 2
Figure 2. Figure 2: We have that τ is Trail, R is the regular expression (likes.hasCreator)+, ω is the where condition x.name = "Moe", ϖ is the return term y.name, and the limit parameter k is equal to 3. First, we apply the translation function TM(R, τ, G) to obtain the path algebra expr…
Figure 6
Figure 6. Figure 6: Query tree that represents the path algebra expression of the declarative path query shown in [PITH_FULL_IMAGE:figures/full_fig_p012_6.png]
Figure 7
Figure 7. Figure 7: Result of executing a path query in the Command Line Interface (CLI) of PathDB. follow the syntax defined by the Property Graph Data Format (PGDF) [10]. 6.2 Baseline algorithms The baseline algorithm for evaluating regular path queries is automata-based graph traversal…
Figure 8
Figure 8. Figure 8: Visual comparison of the execution times obtained by PathDB, for different query patterns, and using four path restrictors (Walk, Trail, Simple, and Acyclic). The specific times are presented in [PITH_FULL_IMAGE:figures/full_fig_p020_8.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Efficient Path Query Processing in Relational Database Systems

    cs.DB 2026-04 unverdicted novelty 7.0 of 10

    ReCAP enables relational DBMS like DuckDB to push property constraints deep into path query plans for speedups up to 400,000x over state-of-the-art graph and relational systems.

Reference graph

Works this paper leans on

29 extracted references · 21 canonical work pages · cited by 1 Pith paper

  1. [1]

    The future is big graphs: a community view on graph processing systems,

    S. Sakr, A. Bonifati, H. Voigt, A. Iosup, K. Ammar, R. Angles, W. Aref, M. Arenas, M. Besta, P. A. Boncz, K. Daudjee, E. D. Valle, S. Dumbrava, O. Hartig, B. Haslhofer, T. Hegeman, J. Hidders, K. Hose, A. Iamnitchi, V. Kalavri, H. Kapp, W. Martens, M. T. ¨Ozsu, E. Peukert, S. Plantikow, M. Ragab, M. R. Ripeanu, S. Salihoglu, C. Schulz, P. Selmer, J. F. Se...

    work page 2021

  2. [2]

    Bonifati, G

    A. Bonifati, G. Fletcher, H. Voigt, and N. Yakovets,Querying Graphs. San Rafael, CA, USA: Morgan & Claypool, oct 2018, vol. 10, no. 3. [Online]. Available: https://doi.org/10.2200/s00873ed1v01y201808dtm051

    doi:10.2200/s00873ed1v01y201808dtm051 2018

  3. [3]

    Foundations of modern query languages for graph databases,

    R. Angles, M. Arenas, P. Barcel´ o, A. Hogan, J. L. Reutter, and D. Vrgoc, “Foundations of modern query languages for graph databases,”ACM Comput. Surv., vol. 50, no. 5, pp. 68:1–68:40, 2017. [Online]. Available: https://doi.org/10.1145/3104031

    doi:10.1145/3104031 2017

  4. [4]

    SPARQL 1.1 Query Language (W3C Recommendation),

    S. Harris and A. Seaborne, “SPARQL 1.1 Query Language (W3C Recommendation),” Mar

    work page

  5. [5]

    Cypher: An evolving query language for property graphs,

    N. Francis, A. Green, P. Guagliardo, L. Libkin, T. Lindaaker, V. Marsault, S. Plantikow, M. Rydberg, P. Selmer, and A. Taylor, “Cypher: An evolving query language for property graphs,” inProc. of the International Conference on Management of Data (SIGMOD). New York, NY, USA: ACM, 2018, pp. 1433–1445. [Online]. Available: https://doi.org/10.1145/3183713.3190657

    arXiv 2018

  6. [6]

    ISO/IEC 39075:2024 Information technology — Database languages — GQL,

    ISO, “ISO/IEC 39075:2024 Information technology — Database languages — GQL,” Apr

    work page 2024

  7. [7]

    ISO/IEC 9075-16:2023 Information technology — Database languages SQL - Part 16: Property Graph Queries (SQL/PGQ),

    ——, “ISO/IEC 9075-16:2023 Information technology — Database languages SQL - Part 16: Property Graph Queries (SQL/PGQ),” Jun. 2023. [Online]. Available: https://www.iso.org/standard/79473.html

    work page 2023

  8. [8]

    Evaluating Regular Path Queries in GQL and SQL/PGQ: How Far Can the Classical Algorithms Take Us?

    B. Far ´ ıas, C. Rojas, and D. Vrgoˇ c, “Evaluating Regular Path Queries in GQL and SQL/PGQ: How Far Can the Classical Algorithms Take Us?”arXiv, no. 2306.02194, 2023. [Online]. Available: http://arxiv.org/abs/2306.02194

    arXiv 2023

Show all 29 references
  1. [9]

    Architecture of a database system,

    J. M. Hellerstein, M. Stonebraker, and J. Hamilton, “Architecture of a database system,” Foundations and Trends in Databases, vol. 1, no. 2, pp. 141–259, Feb. 2007. [Online]. Available: https://doi.org/10.1561/1900000002

    2007 doi

  2. [10]

    The Property Graph Data Format (PGDF),

    R. Angles, S. Ferrada, and I. Burgos, “The Property Graph Data Format (PGDF),”IEEE Access, vol. 12, pp. 159 267–159 279, 2024. [Online]. Available: https://doi.org/10.1109/ ACCESS.2024.3485685

    2024

  3. [11]

    On the optimal time/space tradeoff for hash tables,

    M. A. Bender, M. Farach-Colton, J. Kuszmaul, W. Kuszmaul, and M. Liu, “On the optimal time/space tradeoff for hash tables,” inProceedings of the Annual Symposium on Theory of Computing. New York, NY, USA: ACM, 2022, pp. 1284–1297. [Online]. Available: https://doi.org/10.1145/3...

    2022

  4. [12]

    Finding regular simple paths in graph databases,

    A. O. Mendelzon and P. T. Wood, “Finding regular simple paths in graph databases,” SIAM J. Comput., vol. 24, no. 6, pp. 1235–1258, Dec. 1995. [Online]. Available: https://doi.org/10.1137/S009753979122370X

    1995 doi

  5. [13]

    LDBC Social Network Benchmark (LDBC SNB)

    Graph Data Council, “LDBC Social Network Benchmark (LDBC SNB).” [Online]. Available: https://www.ldbcouncil.org/benchmarks/snb/

  6. [14]

    The LDBC Social Network Benchmark: Interactive Workload,

    O. Erling, A. Averbuch, J. Larriba-Pey, H. Chafi, A. Gubichev, A. Prat, M.-D. Pham, and P. Boncz, “The LDBC Social Network Benchmark: Interactive Workload,” inProc. of the International Conference on Management of Data (SIGMOD). New York, NY, USA: ACM, 2015, pp. 619–630. [Onli...

    2015

  7. [15]

    The LDBC social network benchmark: Business intelligence workload,

    G. Sz´ arnyas, J. Waudby, B. A. Steer, D. Szak´ allas, A. Birler, M. Wu, Y. Zhang, and P. A. Boncz, “The LDBC social network benchmark: Business intelligence workload,”Proc. VLDB Endow., vol. 16, no. 4, pp. 877–890, 2022. [Online]. Available: https://www.vldb.org/pvldb/vol16/p...

    2022

  8. [16]

    Efficient regular path query evaluation using path indexes,

    G. H. Fletcher, J. Peters, and A. Poulovassilis, “Efficient regular path query evaluation using path indexes,” inAdvances in Database Technology – EDBT, vol. 2016-March, 2016, pp. 636– 639

    2016

  9. [17]

    Grid-aware evaluation of regular path queries on spatial networks,

    Z. Miao, D. Stefanescu, and A. Thomo, “Grid-aware evaluation of regular path queries on spatial networks,” inAINA 2007. IEEE, 2007, pp. 158–165

    2007

  10. [18]

    Fine-grained complexity of regular path queries,

    K. Casel and M. L. Schmid, “Fine-grained complexity of regular path queries,”LMCS, vol. 19, no. 4, pp. 1–15, 2023

    2023

  11. [19]

    Evaluating regular path queries on com- pressed adjacency matrices,

    D. Arroyuelo, A. G´ omez-Brand´ on, and G. Navarro, “Evaluating regular path queries on com- pressed adjacency matrices,”The VLDB Journal, vol. 34, no. 1, p. 28, nov 2024

    2024

  12. [20]

    Regular path query evaluation on streaming graphs,

    A. Pacaci, A. Bonifati, and M. T. ¨Ozsu, “Regular path query evaluation on streaming graphs,” inSIGMOD 2020. New York, NY, USA: ACM, 2020, pp. 1415–1430

    2020

  13. [21]

    On the optimization of recursive relational queries: Application to graph queries,

    L. Jachiet, P. Genev` es, N. Gesbert, and N. Layaida, “On the optimization of recursive relational queries: Application to graph queries,” inSIGMOD 2020. New York, NY, USA: ACM, 2020, pp. 681–697

    2020

  14. [22]

    Pathfinder: Returning paths in graph queries,

    B. Far ´ ıas, W. Martens, C. Rojas, and D. Vrgoˇ c, “Pathfinder: Returning paths in graph queries,” inISWC 2024. Berlin, Heidelberg: Springer, 2024, pp. 135–154

    2024

  15. [23]

    G-core: A core for fu- ture graph query languages,

    R. Angles, M. Arenas, P. Barcel´ o, P. Boncz, G. Fletcher, C. Gutierrez, T. Lindaaker, M. Paradies, S. Plantikow, J. Sequeda, O. van Rest, and H. Voigt, “G-core: A core for fu- ture graph query languages,” inSIGMOD 2018. New York, NY, USA: ACM, 2018, pp. 1421–1432

    2018

  16. [24]

    Path algebra and algorithms,

    M. Gondran, “Path algebra and algorithms,” inCombinatorial Programming: Methods and Applications. Dordrecht: Springer, 1975, pp. 137–148

    1975

  17. [25]

    A new path algebra for finding paths in graphs,

    R. Manger, “A new path algebra for finding paths in graphs,” inInt. Conf. on Information Technology Interfaces (ITI), 2004, pp. 657–662

    2004

  18. [26]

    A path algebra for multi-relational graphs,

    M. A. Rodriguez and P. Neubauer, “A path algebra for multi-relational graphs,” inInt. Conf. on Data Engineering Workshops (ICDEW). IEEE, 2011, pp. 128–131. 24

    2011

  19. [27]

    Neo4j graph platform – the leader in graph databases,

    Neo4j, “Neo4j graph platform – the leader in graph databases,” 2022, accessed: 2021-03-21. [Online]. Available: https://neo4j.com/ A PathDB Declarative Query Language Grammar. <pathQuery> ::= <matchClause> <whereClause> <returnClause> <matchClause> ::= "MATCH" <restrictor>? <p...

    2022

  20. [2013]

    Available: https://www.w3.org/TR/sparql11-query/

    [Online]. Available: https://www.w3.org/TR/sparql11-query/

  21. [2024]

    Available: https://www.iso.org/standard/76120.html

    [Online]. Available: https://www.iso.org/standard/76120.html

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.