Pith. sign in

REVIEW 2 cited by

Leapfrog Triejoin: a worst-case optimal join algorithm

Not yet reviewed by Pith; the record is open.

This paper has not been read by Pith yet. Machine review is queued; the pith claim, tier, and objections will appear here once it completes.

SPECIMEN: schema-true, not a live event

T0 review · schema-true

One-sentence machine reading of the paper's core claim.

pith:XXXXXXXX · record.json · timestamp

arxiv 1210.0481 v5 pith:2AKJIT5S submitted 2012-10-01 cs.DB cs.DS

classification cs.DBcs.DS
keywords leapfrogtriejoinnprralgorithmjoinworst-caseoptimaltime
verification ladder T0 review T1 audit T2 compute T3 formal
0 comments
abstract

Recent years have seen exciting developments in join algorithms. In 2008, Atserias, Grohe and Marx (henceforth AGM) proved a tight bound on the maximum result size of a full conjunctive query, given constraints on the input relation sizes. In 2012, Ngo, Porat, R{\'e} and Rudra (henceforth NPRR) devised a join algorithm with worst-case running time proportional to the AGM bound. Our commercial Datalog system LogicBlox employs a novel join algorithm, \emph{leapfrog triejoin}, which compared conspicuously well to the NPRR algorithm in preliminary benchmarks. This spurred us to analyze the complexity of leapfrog triejoin. In this paper we establish that leapfrog triejoin is also worst-case optimal, up to a log factor, in the sense of NPRR. We improve on the results of NPRR by proving that leapfrog triejoin achieves worst-case optimality for finer-grained classes of database instances, such as those defined by constraints on projection cardinalities. We show that NPRR is \emph{not} worst-case optimal for such classes, giving a counterexample where leapfrog triejoin runs in $O(n \log n)$ time, compared to $\Theta(n^{1.375})$ time for NPRR. On a practical note, leapfrog triejoin can be implemented using conventional data structures such as B-trees, and extends naturally to $\exists_1$ queries. We believe our algorithm offers a useful addition to the existing toolbox of join algorithms, being easy to absorb, simple to implement, and having a concise optimality proof.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

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

  1. BaCon: Efficient Batch Processing of Counting Queries [Full Version]

    cs.DB 2026-07 accept novelty 6.0 of 10

    BaCon combines factorized join computation with workload-aware domain quantization to evaluate batches of counting queries 2×–178× faster than independent or post-filtering baselines, without modifying DBMS internals.

  2. A Unified Architecture for Efficient Binary and Worst-Case Optimal Join Processing

    cs.DB 2025-05 conditional novelty 4.0 of 10

    A query engine that supports both hash-based and sort-based worst-case optimal joins reports average speedups of 1.4x to 1.5x and a maximum of 4.8x over the Free Join framework.

Pith tools