Skip to content

[SPARK-50903][CONNECT] Cache logical plans after analysis #49584

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

changgyoopark-db
Copy link
Contributor

@changgyoopark-db changgyoopark-db commented Jan 21, 2025

What changes were proposed in this pull request?

Update the plan cache after logical plans are analyzed.

  • The plan cache is only read-accessed during logical plan transformation and never updated.
  • The plan cache is updated once a data frame of the relation is created, which is when a logical plan has been analyzed.
  • The expected number of accesses to the plan cache is the same.

Additionally, this PR includes,

  • Plan cache code refactoring: see the next section for the common coding pattern.
  • Add a plan freshness check method to SessionHolder for future usage.

Why are the changes needed?

The session local plan cache may store unanalyzed logical plans, which causes them to be repeatedly analyzed, resulting in performance degradation.

To be specific, the session local plan cache usage pattern is,

val plan = planner.transformRelation(request.getPlan.getRoot, cachePlan = true)
val dataframe = Dataset.ofRows(session, plan) 

Where an unanalyzed plan may be cached during transformation, and Dataset.ofRows analyzes the unanalyzed plan. This leads to a situation where the same query may hit the cache, returning an unanalyzed plan, and Dataset.ofRows again analyzes the same plan.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

testOnly org.apache.spark.sql.connect.service.SparkConnectSessionHolderSuite

Was this patch authored or co-authored using generative AI tooling?

No.

@changgyoopark-db changgyoopark-db force-pushed the SPARK-50903 branch 2 times, most recently from db8db47 to 8b1df40 Compare January 21, 2025 11:54
@changgyoopark-db changgyoopark-db changed the title [WIP][SPARK_50903][CONNECT] Let the plan cache only contain analysed plans [SPARK_50903][CONNECT] Let the plan cache only contain analysed plans Jan 21, 2025
@changgyoopark-db changgyoopark-db changed the title [SPARK_50903][CONNECT] Let the plan cache only contain analysed plans [SPARK-50903][CONNECT] Let the plan cache only contain analysed plans Jan 21, 2025
@changgyoopark-db changgyoopark-db changed the title [SPARK-50903][CONNECT] Let the plan cache only contain analysed plans [SPARK-50903][CONNECT] Let the plan cache only contain resolved plans Jan 21, 2025
@changgyoopark-db changgyoopark-db changed the title [SPARK-50903][CONNECT] Let the plan cache only contain resolved plans [SPARK-50903][CONNECT] Let the plan cache only contain analyzed plans Jan 21, 2025
@changgyoopark-db changgyoopark-db force-pushed the SPARK-50903 branch 2 times, most recently from 6fc5c1b to 38d2d1d Compare January 21, 2025 13:38
@changgyoopark-db changgyoopark-db changed the title [SPARK-50903][CONNECT] Let the plan cache only contain analyzed plans [SPARK-50903][CONNECT] Let the plan cache try to analyse plans before storing them Jan 21, 2025
@changgyoopark-db changgyoopark-db force-pushed the SPARK-50903 branch 5 times, most recently from 022f1e3 to 4264bdd Compare January 22, 2025 12:12
@changgyoopark-db changgyoopark-db force-pushed the SPARK-50903 branch 4 times, most recently from e948a7c to 5962637 Compare January 22, 2025 14:19
@changgyoopark-db changgyoopark-db marked this pull request as draft January 23, 2025 13:17
@github-actions github-actions bot removed the PYTHON label Jan 23, 2025
@changgyoopark-db changgyoopark-db changed the title [SPARK-50903][CONNECT] Let the plan cache try to analyse plans before storing them [SPARK-50903][CONNECT] Update plan cache entries after analysis Jan 23, 2025
@changgyoopark-db changgyoopark-db force-pushed the SPARK-50903 branch 2 times, most recently from 7b7430f to 622bac9 Compare January 23, 2025 16:37
@changgyoopark-db changgyoopark-db marked this pull request as ready for review January 23, 2025 16:39
@changgyoopark-db changgyoopark-db force-pushed the SPARK-50903 branch 5 times, most recently from ca61632 to 1f8594e Compare January 24, 2025 12:25
@changgyoopark-db
Copy link
Contributor Author

changgyoopark-db commented Jan 24, 2025

@xi-db FYI
@hvanhovell
Hi, can you review this PR when you have time?

  • Plans are not cached during transformation.
  • Plans are cached once after data frames are created (after analysis).
  • The number of cache get/put calls stays the same; only the timing was adjusted.
    Thanks!

@changgyoopark-db changgyoopark-db changed the title [SPARK-50903][CONNECT] Update plan cache entries after analysis [SPARK-50903][CONNECT] Cache logical plans after analysis Jan 27, 2025
@changgyoopark-db changgyoopark-db force-pushed the SPARK-50903 branch 2 times, most recently from 43b810f to 5981821 Compare January 28, 2025 09:41
Copy link
Contributor

@hvanhovell hvanhovell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR looks good.

logDebug(s"Cache a lazyily analyzed logical plan for '$rel': $plan")
planCache.get.put(rel, plan)
} else {
val plan = df.queryExecution.analyzed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may have to add some invalidation logic here. The problem is that some of objects (tables/views/udfs) used in the query can change, in that case we may want to validate that the objects used are the most recent ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I'll need to think about the interface.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added LogicalPlan.isOutdated and updated the usePlanCache method.
-> Calling 'refresh' seemed suboptimal, as schema changes often require a re-planning of the plan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants