Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Towards Cross-Model Efficiency in SQL/PGQ

Hadar Rotschield, Liat Peterfreund

TL;DR

This work investigates how SQL/PGQ, which blends relational and graph querying, affects performance when queries are written as SQL or graph patterns. Through cross-system experiments on DuckDB with DuckPGQ, Google Cloud Spanner, and Neo4j, it shows that execution efficiency hinges on internal optimizations and plans rather than mere syntax, with some systems favoring SQL/PGQ and others favoring SQL. The authors argue for holistic optimization that decouples language form from execution, proposing internal rewriting and cross-model algorithm integration as two promising directions. The findings highlight the potential and challenges of unified optimization for hybrid graph-relational workloads in real-world DBMSs.

Abstract

SQL/PGQ is a new standard that integrates graph querying into relational systems, allowing users to freely switch between graph patterns and SQL. Our experiments show performance gaps between these models, as queries written in both formalisms can exhibit varying performance depending on the formalism used, suggesting that current approaches handle each query type separately, applying distinct optimizations to each formalism. We argue that a holistic optimization is necessary, where the system internally decides on the best algorithms regardless of whether queries are written in SQL or as graph patterns. We propose possible future research direction to unify these optimizations and mitigate performance gaps.

Towards Cross-Model Efficiency in SQL/PGQ

TL;DR

This work investigates how SQL/PGQ, which blends relational and graph querying, affects performance when queries are written as SQL or graph patterns. Through cross-system experiments on DuckDB with DuckPGQ, Google Cloud Spanner, and Neo4j, it shows that execution efficiency hinges on internal optimizations and plans rather than mere syntax, with some systems favoring SQL/PGQ and others favoring SQL. The authors argue for holistic optimization that decouples language form from execution, proposing internal rewriting and cross-model algorithm integration as two promising directions. The findings highlight the potential and challenges of unified optimization for hybrid graph-relational workloads in real-world DBMSs.

Abstract

SQL/PGQ is a new standard that integrates graph querying into relational systems, allowing users to freely switch between graph patterns and SQL. Our experiments show performance gaps between these models, as queries written in both formalisms can exhibit varying performance depending on the formalism used, suggesting that current approaches handle each query type separately, applying distinct optimizations to each formalism. We argue that a holistic optimization is necessary, where the system internally decides on the best algorithms regardless of whether queries are written in SQL or as graph patterns. We propose possible future research direction to unify these optimizations and mitigate performance gaps.
Paper Structure (23 sections, 7 figures, 6 tables)

This paper contains 23 sections, 7 figures, 6 tables.

Table of Contents

  1. Introduction
  2. Related Work
  3. Querying Property Graphs in SQL/PGQ
  4. From SQL/PGQ to (Recursive) SQL
  5. Empirical Analysis
  6. Datasets Generation
  7. Query Scenarios
  8. SQL/PGQ Support Across Systems
  9. SQL vs. SQL/PGQ in Spanner and DuckDB (Figure \ref{['fig:sql_pgq_results']} and Table \ref{['tab:merged-factor-diffs']})
  10. Neo4j (Figure \ref{['fig:neo4j_results']})
  11. Graph Creation Times (Table \ref{['tab:graph_creation_latency']})
  12. Summary
  13. Conclusion and Future Directions
  14. Theoretical Approaches to Algorithm Optimization
  15. Internal Rewriting
  16. ...and 8 more sections

Figures (7)

  • Figure 1: Execution time (ms) as a function of dataset size (#rows) for DuckDB (bounded & unbounded queries) and Spanner (bounded queries).
  • Figure 2: Comparison of execution time (ms) as a function of dataset size (#rows) for Neo4j queries (in Cypher).
  • Figure 3: Relational tables dataset with account, own, person, friends, and transfer.
  • Figure 4: Comparison of execution time (ms) as a function of dataset size (#rows) for SQL/PGQ queries for DuckDB (1-3 bounded queries)
  • Figure 5: Comparison of execution time (ms) as a function of dataset size (#rows) for SQL/PGQ queries for DuckDB (4-6 unbounded queries)
  • ...and 2 more figures