ExtGraph: Direct Graph Extraction

Updated 12 July 2026

The paper introduces ExtGraph, a method that directly extracts user-intended graphs from relational workloads by optimizing complex join operations.
It employs dual join-sharing techniques—JS-OJ for merging queries with outer joins and JS-MV for materialized view reuse—to efficiently handle diverse join patterns.
Experimental results show ExtGraph outperforms state-of-the-art methods by up to 2.78x, demonstrating significant efficiency gains in real-world database scenarios.

ExtGraph is a graph extraction method for relational databases that is designed to produce user-intended graphs directly from SQL join workloads rather than from only foreign-key structure. Its central systems idea is to optimize graph extraction by hybrid query processing of outer join and materialized view, so that shared joins across multiple edge-definition queries are reused without introducing the virtual vertices and virtual edges characteristic of some earlier approaches (Park et al., 23 Sep 2025).

1. Problem setting and the notion of a user-intended graph

ExtGraph addresses a recurrent mismatch between data storage and graph analytics. In many organizations, important data remains in relational DBMSs, while graph analytics is used to study recommendation, fraud detection, social analysis, bioinformatics, and AI or knowledge-graph workloads. In this setting, the graph is not stored explicitly; it must first be extracted from relational data. The paper distinguishes two broad approaches: translating graph queries into relational queries, or extracting a graph first and then executing graph analytics on the extracted graph. ExtGraph targets the second approach (Park et al., 23 Sep 2025).

The method is organized around the idea of a user-intended graph. In this usage, graph edges are not restricted to simple foreign-key links. Instead, they are defined by relational join queries that express the relationships users actually want to analyze. The examples given include edges between customers who bought the same product (Co-pur), customers who saw the same promotion (Same-pro), a customer and an item purchased with a promotion (Get-disc), a store and products it sells (Sell), and a customer and products it bought (Buy). These relationships may require chain joins, star joins, or cyclic joins rather than a single schema-derived edge pattern (Park et al., 23 Sep 2025).

This focus places ExtGraph between two prior families of systems. Schema-based extraction methods are efficient, but they cannot express many graph edges users actually care about. Join workload-based methods are expressive, but they often become slow because each edge definition may require expensive joins, including many-way joins and $N$ -to- $N$ joins. Prior systems such as GraphGen and R2GSync reduce some extraction cost by decomposing complex edge queries into smaller pieces, but the result is not the original intended graph: one conceptual edge becomes a path through virtual graph elements, and recovering the actual graph requires post-processing. ExtGraph is intended to preserve join-workload expressiveness while extracting the intended graph directly (Park et al., 23 Sep 2025).

2. Formal graph model and relational abstraction

The method formalizes graph extraction from a relational database instance $D=\{R_i\}$ by defining a graph model

$M=(M_v, M_e),$

where $M_v$ is a set of vertex definitions and $M_e$ is a set of edge definitions. A vertex definition is

$m_v=(l_v, R_v)\in M_v,$

where $l_v$ is the vertex label and $R_v$ is a table whose tuples define vertices of that label. An edge definition is

$m_e=(l_e, m_{src}, m_{dst}, Q)\in M_e,$

where $N$ 0 is the edge label, $N$ 1 and $N$ 2 are the source and destination vertex definitions, and $N$ 3 is a query representing the join relationship between two vertices. Each tuple in the result of $N$ 4 defines one edge of label $N$ 5 (Park et al., 23 Sep 2025).

On this basis, graph extraction produces a directed multigraph $N$ 6. ExtGraph revises the ordinary extraction workflow by inserting an optimization phase. The resulting process is: define a graph model $N$ 7, optimize edge definitions using join sharing techniques, extract a set of vertices and a set of edges from $N$ 8, and convert them into a graph. The method is therefore not a graph query language or a graph store in its own right; it is an extraction-time optimization framework (Park et al., 23 Sep 2025).

A concrete example is the RetailG graph. It defines Customer vertices from table C, Item vertices from table I, a GetDisc edge from a cyclic query over C, SS, P, and I, and a CoPur edge from a chain-style query over C1, SS1, I, SS2, and C2. This example is used to emphasize that ExtGraph supports arbitrary join-form edge definitions, not only chain joins (Park et al., 23 Sep 2025).

To optimize such workloads, each edge-definition query is converted into a join graph. In this representation, a vertex indicates a table in the query, an edge indicates a join between tables, $N$ 9 denotes the join type, and $D=\{R_i\}$ 0 denotes the join condition. ExtGraph then identifies a shared subgraph between two join graphs as a connected component of common joins with matching join type and join condition. This abstraction allows the optimizer to reason structurally about shared join fragments across edge definitions (Park et al., 23 Sep 2025).

ExtGraph’s main technical contribution is the combination of two join-sharing techniques: JS-OJ and JS-MV. Both seek to exploit overlap among edge-definition queries, but they do so differently and under different cost conditions (Park et al., 23 Sep 2025).

JS-OJ merges related edge-definition queries into a single query using outer joins. If two join graphs share a common subgraph $D=\{R_i\}$ 1, each query is decomposed into $D=\{R_i\}$ 2 plus its non-shared subgraphs. The merged query retains the shared part once and attaches the non-shared parts via outer joins. The paper’s rationale is semantic: if the query-specific parts were attached with inner joins, one side could filter tuples needed by the other side. Outer joins prevent this interference because they preserve tuples from the designated outer side. ExtGraph enumerates possible decompositions, constructs merged join graphs, estimates their costs, and chooses the cheapest merged plan (Park et al., 23 Sep 2025).

The correctness claim for JS-OJ is explicit. Theorem 1 states that the result of the original queries can be retrieved without loss or error by performing the selected merged plan $D=\{R_i\}$ 3. The proof idea is that outer joins preserve tuples from the shared side, and extra tuples introduced by the outer-join structure contain nulls; tuples with non-null values correspond to valid results from the original queries (Park et al., 23 Sep 2025).

JS-MV is used when direct merging would create a harmful increase in join complexity, especially through large $D=\{R_i\}$ 4-to- $D=\{R_i\}$ 5 interactions. In that case, ExtGraph computes the shared join once, stores it as a materialized view, and rewrites the original edge-definition queries to use that view. JS-MV avoids repeated execution of the shared join without forcing unrelated query-specific components into a single monolithic outer-join plan. Its drawback is the materialization overhead: computing the view costs time and storing it incurs I/O (Park et al., 23 Sep 2025).

The paper positions this dual design against GraphGen and R2GSync. ExtGraph’s novelty is not only join reuse, but direct extraction of user-intended graphs without virtual edges/vertices and without post-processing. In this sense, its primary concern is semantic fidelity during extraction, not merely lower intermediate cost (Park et al., 23 Sep 2025).

4. Cost model and hybrid optimization

The optimizer chooses among baseline execution, JS-OJ, and JS-MV by means of an explicit cost model. For $D=\{R_i\}$ 6 edge-definition queries $D=\{R_i\}$ 7, the baseline cost is

$D=\{R_i\}$ 8

The paper assumes only left-deep binary join plans and hash joins. Under that assumption,

$D=\{R_i\}$ 9

For a merged query $M=(M_v, M_e),$ 0 under JS-OJ, the cost is

$M=(M_v, M_e),$ 1

with outer-join combination cost

$M=(M_v, M_e),$ 2

For JS-MV, if $M=(M_v, M_e),$ 3 materialized views are created, the cost is

$M=(M_v, M_e),$ 4

Here $M=(M_v, M_e),$ 5 denotes the rewritten edge-definition query, $M=(M_v, M_e),$ 6 the cost of accessing a disk page, and $M=(M_v, M_e),$ 7 the number of disk pages containing the view (Park et al., 23 Sep 2025).

The optimizer itself is a greedy heuristic optimizer. It starts from the baseline plan, enumerates candidate transformations obtainable by one application of JS-OJ or JS-MV, estimates their costs, adopts the lowest-cost improvement, and repeats until no cheaper plan is found. The paper gives a worked example with three queries $M=(M_v, M_e),$ 8 and an initial baseline cost of $M=(M_v, M_e),$ 9. Candidate transformations are evaluated at costs $M_v$ 0, $M_v$ 1, $M_v$ 2, and $M_v$ 3; the optimizer first selects JS-MV at cost $M_v$ 4, then JS-OJ at cost $M_v$ 5, yielding a hybrid final plan. This example is used to show that different shared joins may be best optimized in different ways (Park et al., 23 Sep 2025).

5. Experimental evaluation

The evaluation uses TPC-DS with scale factors SF=10, 30, 100, plus DBLP and IMDB. In TPC-DS, two scenarios are defined: a recommendation scenario and a fraud detection scenario. Since TPC-DS includes three sales channels—Store, Catalog, Web—the experiments use six graph models in total. The real-data models include an Auth-Edit relationship in DBLP, and Wri-Dir and Act-Dir relationships in IMDB. Experiments run on one server with two 16-core 3.0 GHz CPUs, 1 TB memory, 14 TB hard disk, Ubuntu 18.04.4, and PostgreSQL 14.4 as the base system (Park et al., 23 Sep 2025).

ExtGraph is compared with Ringo, GraphGen, and R2GSync. For fairness, the measured time for GraphGen and R2GSync includes the conversion needed to recover the same user-intended graph produced directly by Ringo and ExtGraph. This matters because GraphGen and R2GSync natively output structures containing virtual graph elements (Park et al., 23 Sep 2025).

The main reported result is that ExtGraph outperforms the state-of-the-art methods up to by 2.78x in terms of graph extraction time. Representative results are as follows:

Setting	Reported result	Comparison
TPC-DS recommendation	2.34X	ExtGraph over Ringo at SF 10
TPC-DS fraud detection	2.78X	ExtGraph over R2GSync at SF 30
DBLP	669.9 sec	Ringo 769.2 sec; GraphGen 1866.6 sec; R2GSync 1882.1 sec
IMDB	71.2 sec	Ringo 88.4 sec; GraphGen 116.4 sec; R2GSync 388.8 sec

The ablation study isolates the two join-sharing techniques on a TPC-DS graph model containing Sell, Buy, Co-pur, and Same-pro. Four configurations are compared: no join sharing, JS-OJ only, JS-MV only, and the hybrid plan. The hybrid plan performs best. The explanation is specific: JS-MV alone is better than JS-OJ alone for Co-pur and Same-pro, where direct query merging is less favorable, but the hybrid plan outperforms JS-MV alone because Sell and Buy can use JS-OJ and thereby avoid materializing those query results (Park et al., 23 Sep 2025).

6. Scope, limitations, and relation to adjacent graph systems

ExtGraph is not presented as universally optimal under all workloads. Its own analysis identifies several trade-offs. JS-OJ can backfire when merging queries creates expensive additional $M_v$ 6-to- $M_v$ 7 joins. JS-MV incurs materialization I/O cost, so it is not always advantageous to materialize a shared subquery. The hybrid planner is a greedy heuristic optimizer, not an exhaustive global search. The cost model is simplified by its assumptions of left-deep plans, hash joins, and disk-backed materialized views. The paper also characterizes ExtGraph’s extraction cost as medium: it is more efficient than independent query execution, but unlike GraphGen and R2GSync it does not reduce extraction cost by changing the graph semantics (Park et al., 23 Sep 2025).

Within the broader graph-systems landscape, ExtGraph occupies a distinct position. GraphPaper is an environment for graph creation, visualization, and transformation specialized to interaction nets and coupled to TULIP (Fernández et al., 2010). ELK is a collection of graph drawing algorithms that supports compound graph layout and ports as explicit anchor points of edges (Domrös et al., 2023). EGML is an XML application for representing evolving graphs as timestamped graph-instance sequences (Chapanond et al., 2010). GSS is a graph stream sketch with linear space $M_v$ 8, practical $M_v$ 9 update, and topology-aware approximate queries (Gou et al., 2018). ExtGraph differs from these systems in that its primary problem is neither layout, nor interactive rewriting, nor temporal representation, nor graph-stream summarization. It is concerned with the pre-analytics construction of graphs from relational workloads.

This suggests that ExtGraph belongs to a specific infrastructural layer of graph processing: the layer that turns relational data into a graph faithful to the relationships users actually intend to analyze. Its contribution is therefore best understood not as a new graph model, but as a cost-based extraction architecture that treats join sharing, semantic fidelity, and direct graph materialization as a unified systems problem (Park et al., 23 Sep 2025).