You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Bruno Messias (Jira)" <ji...@apache.org> on 2026/02/04 01:04:00 UTC

[jira] [Created] (SPARK-55348) async_track expressions for efficient convergent algorithms in recursive CTEs (avoids exponential blowup)

Bruno Messias created SPARK-55348:
-------------------------------------

             Summary: async_track expressions for efficient convergent algorithms in recursive CTEs (avoids exponential blowup)
                 Key: SPARK-55348
                 URL: https://issues.apache.org/jira/browse/SPARK-55348
             Project: Spark
          Issue Type: New Feature
          Components: SQL
    Affects Versions: 4.1.1
            Reporter: Bruno Messias


This proposal introduces a *family of stateful expressions* (`async_track_min`, `async_track_max`, `async_track_...`) that prevent exponential row explosion in recursive CTEs for graph algorithms for example. These expressions filter redundant rows during iteration by tracking the "best" value seen for each key.

{*}Why it works{*}: For operators like `min`, `max`, and `first-seen` etc, the result is the same regardless of processing order. Spark's distributed task  is actually an advantage here: zero coordination overhead, with correctness guaranteed by the mathematical properties of these operators.

{*}Complexity improvement{*}: Without filtering, recursive CTEs enumerate all paths (exponential in graph density). With `async_track`, each key is accepted at most once per iteration, reducing worst-case complexity 


h3. Motivation: Need for Efficient Recursive CTEs

The introduction of recursive CTEs in Spark  was a significant step forward. I work in financial services where we are usubg recursive CTEs 

However, there's a hard ceiling: {*}row explosion{*}. Once graphs exceed a certain density or depth, queries become impractical due to exponential intermediate row growth. This forces teams to either:
 * Limit query scope to small subgraphs
 * Accept long runtimes and high compute costs
 * Move data to external graph systems (breaking the SQL-native workflow) and going outside from databrick



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org