Skip to content

[SPARK-33612][SQL] Add dataSourceRewriteRules batch to Optimizer #30558

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.

Sign up for GitHub

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

Closed
aokolnychyi wants to merge 3 commits into from
Closed

[SPARK-33612][SQL] Add dataSourceRewriteRules batch to Optimizer #30558

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b340917
[SPARK-33612][SQL] Add v2SourceRewriteRules batch to Optimizer
aokolnychyi Nov 30, 2020
ec31aec
Rework approach
aokolnychyi Dec 1, 2020
11f07cd
Change name
aokolnychyi Dec 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/Optimizer.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -185,6 +185,9 @@ abstract class Optimizer(catalogManager: CatalogManager)
RemoveLiteralFromGroupExpressions,
RemoveRepetitionFromGroupExpressions) :: Nil ++
operatorOptimizationBatch) :+
// This batch rewrites data source plans and should be run after the operator
// optimization batch and before any batches that depend on stats.
Batch("Data Source Rewrite Rules", Once, dataSourceRewriteRules: _*) :+
Copy link
Member

@gatorsmile gatorsmile Dec 2, 2020

Choose a reason for hiding this comment

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

Basically, what you want to do is to add an extension point/batch between heuristics-based optimizer and cost-based optimizer.

The batch name and comments look not good to me. We need a better name here.

Copy link
Member

@gatorsmile gatorsmile Dec 2, 2020

Choose a reason for hiding this comment

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

cc @maryannxue @hvanhovell

Copy link
Member

@dongjoon-hyun dongjoon-hyun Dec 2, 2020

Choose a reason for hiding this comment

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

Could you propose a name then, @gatorsmile ?

Copy link
Contributor Author

@aokolnychyi aokolnychyi Dec 2, 2020

Choose a reason for hiding this comment

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

I am open to alternatives.

Copy link
Contributor

@maryannxue maryannxue Dec 9, 2020

Choose a reason for hiding this comment

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

We should probably combine this batch with the one below: earlyScanPushDownRules, and give it a more general name similar to extendedOperatorOptimizationRules.

Copy link
Contributor

@cloud-fan cloud-fan Dec 15, 2020

Choose a reason for hiding this comment

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

I'd vote for preCBORules.

Copy link
Member

@dongjoon-hyun dongjoon-hyun Dec 15, 2020

Choose a reason for hiding this comment

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

According to the current discussion, could you make a follow-up PR with preCBORules, @aokolnychyi ? If we have a PR, it would be easier to make a final decision.

Copy link
Contributor

@rdblue rdblue Dec 15, 2020

Choose a reason for hiding this comment

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

I don't think that preCBORules is a good name. This batch is for rewrites that need to happen after basic optimization simplifies expressions and then pushes filters and projections. It also needs to happen before early pushdown, which in turn needs to come before CBO. All of that is before CBO, and that name doesn't capture what this is to be used for.

A more descriptive name is "planRewriteRules" because this is for rewriting plans after initial optimization, but before other optimizer rules that need to run after that rewrite, like early pushdown, CBO, etc.

The name "postOperatorOptimizationRules" is okay, but not very descriptive.

Copy link
Contributor Author

@aokolnychyi aokolnychyi Dec 16, 2020

Choose a reason for hiding this comment

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

Let's finish this discussion in a separate PR. I'll create one now.

Copy link
Contributor Author

@aokolnychyi aokolnychyi Dec 16, 2020

Choose a reason for hiding this comment

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

I created PR #30808

// This batch pushes filters and projections into scan nodes. Before this batch, the logical
// plan may contain nodes that do not report stats. Anything that uses stats must run after
// this batch.
Expand Down Expand Up @@ -289,6 +292,12 @@ abstract class Optimizer(catalogManager: CatalogManager)
*/
def earlyScanPushDownRules: Seq[Rule[LogicalPlan]] = Nil

/**
* Override to provide additional rules for rewriting data source plans. Such rules will be
* applied after operator optimization rules and before any rules that depend on stats.
*/
def dataSourceRewriteRules: Seq[Rule[LogicalPlan]] = Nil

/**
* Returns (defaultBatches - (excludedRules - nonExcludableRules)), the rule batches that
* eventually run in the Optimizer.
Expand Down
11 changes: 11 additions & 0 deletions sql/core/src/main/scala/org/apache/spark/sql/internal/BaseSessionStateBuilder.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -240,6 +240,9 @@ abstract class BaseSessionStateBuilder(
override def earlyScanPushDownRules: Seq[Rule[LogicalPlan]] =
super.earlyScanPushDownRules ++ customEarlyScanPushDownRules

override def dataSourceRewriteRules: Seq[Rule[LogicalPlan]] =
super.dataSourceRewriteRules ++ customDataSourceRewriteRules

override def extendedOperatorOptimizationRules: Seq[Rule[LogicalPlan]] =
super.extendedOperatorOptimizationRules ++ customOperatorOptimizationRules
}
Expand All @@ -263,6 +266,14 @@ abstract class BaseSessionStateBuilder(
*/
protected def customEarlyScanPushDownRules: Seq[Rule[LogicalPlan]] = Nil

/**
* Custom rules for rewriting data source plans to add to the Optimizer. Prefer overriding
* this instead of creating your own Optimizer.
*
* Note that this may NOT depend on the `optimizer` function.
*/
protected def customDataSourceRewriteRules: Seq[Rule[LogicalPlan]] = Nil
Copy link
Member

@gatorsmile gatorsmile Dec 2, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

This name does not explain the goal. IMO, this is misleading. Let us make the API name more general. It is not related to the data sources.


/**
* Planner that converts optimized logical plans to physical plans.
*
Expand Down