Skip to content
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

Fix regression in cost-based optimizer when calculating cost for Window operations #2491

Merged
merged 3 commits into from
May 25, 2021

Conversation

andygrove
Copy link
Contributor

Signed-off-by: Andy Grove andygrove@nvidia.com

Closes #2489

…w operations

Signed-off-by: Andy Grove <andygrove@nvidia.com>
@andygrove andygrove added the bug Something isn't working label May 24, 2021
@andygrove andygrove added this to the May 24 - Jun 4 milestone May 24, 2021
@andygrove andygrove self-assigned this May 24, 2021
@andygrove andygrove changed the title Fix regression in cost-based optimizer when calculting cost for Window operations Fix regression in cost-based optimizer when calculating cost for Window operations May 24, 2021
@@ -351,6 +359,13 @@ object MemoryCostHelper {
def calculateCost(dataSize: Long, memorySpeed: Double): Double = {
(dataSize / GIGABYTE) / memorySpeed
}

def isWindowExpr[INPUT <: Expression](expr: BaseExprMeta[INPUT]) = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we change the name of this? A WindowExpression is something different that does have a type. It has children that might now, but the name to be feels broken.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would isUnevaluableWindowExpr be appropriate?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe this method can be a catch all for all expressions whose cost cannot be evaluated, and the name should not refer to a specific flavor of expressions?

@@ -351,6 +359,13 @@ object MemoryCostHelper {
def calculateCost(dataSize: Long, memorySpeed: Double): Double = {
(dataSize / GIGABYTE) / memorySpeed
}

def isWindowExpr[INPUT <: Expression](expr: BaseExprMeta[INPUT]) = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe this method can be a catch all for all expressions whose cost cannot be evaluated, and the name should not refer to a specific flavor of expressions?

@@ -308,6 +312,10 @@ class GpuCostModel(conf: RapidsConf) extends CostModel {
}

private def exprCost[INPUT <: Expression](expr: BaseExprMeta[INPUT], rowCount: Double): Double = {
if (MemoryCostHelper.isWindowExpr(expr)) {
// Window expressions are Unevaluable and accessing dataType causes an exception
return 0
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we use 0d for consistency with the uses of zero just below it. I think0.0 is actually more Scala-esque but consistency is most important.

@@ -308,6 +312,10 @@ class GpuCostModel(conf: RapidsConf) extends CostModel {
}

private def exprCost[INPUT <: Expression](expr: BaseExprMeta[INPUT], rowCount: Double): Double = {
if (MemoryCostHelper.isWindowExpr(expr)) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

We can also make CBO best effort to minimize effect on production systems:

def exprCost(expr) = Try(doExprCost(expr)).recover {
   case _ if (!RapidsConf.isTestEnabled) => 0.0 
 // add some diagnostics logging too, or have a counter for unsuccessful cost estimates
}.get

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This feature is experimental and disabled by default. The implementation is likely to change a lot still so I think it might be premature for this type of hardening.

andygrove added 2 commits May 24, 2021 13:51
Signed-off-by: Andy Grove <andygrove@nvidia.com>
Signed-off-by: Andy Grove <andygrove@nvidia.com>
@andygrove
Copy link
Contributor Author

build

@andygrove andygrove merged commit b304e67 into NVIDIA:branch-21.06 May 25, 2021
@andygrove andygrove deleted the cbo-window-expr branch May 25, 2021 01:49
nartal1 pushed a commit to nartal1/spark-rapids that referenced this pull request Jun 9, 2021
nartal1 pushed a commit to nartal1/spark-rapids that referenced this pull request Jun 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Queries with window expressions fail when cost-based optimizer is enabled
3 participants