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

executor: support window func for aggregate without frame clause #8899

Merged
merged 18 commits into from
Jan 15, 2019

Conversation

alivxxx
Copy link
Contributor

@alivxxx alivxxx commented Jan 2, 2019

What problem does this PR solve?

Support the execution of aggregations without frame clause for window functions.

What is changed and how it works?

Add a new executor and evaluation framework for window functions.

Check List

Tests

  • Unit test

Code changes

  • Has exported function/method change

Side effects

  • None

Related changes

  • None

This change is Reviewable

@alivxxx alivxxx added type/enhancement The issue or PR belongs to an enhancement. status/DNM sig/execution SIG execution labels Jan 2, 2019
executor/window.go Show resolved Hide resolved
expression/column.go Outdated Show resolved Hide resolved
executor/aggregate.go Show resolved Hide resolved
executor/builder.go Show resolved Hide resolved
planner/core/resolve_indices.go Outdated Show resolved Hide resolved
planner/core/logical_plan_builder.go Outdated Show resolved Hide resolved
executor/windowfuncs/window_funcs.go Outdated Show resolved Hide resolved
executor/windowfuncs/window_funcs.go Outdated Show resolved Hide resolved
executor/windowfuncs/window_funcs.go Outdated Show resolved Hide resolved
executor/windowfuncs/window_funcs.go Outdated Show resolved Hide resolved
executor/windowfuncs/window_funcs.go Outdated Show resolved Hide resolved
executor/windowfuncs/window_funcs.go Outdated Show resolved Hide resolved
executor/window.go Outdated Show resolved Hide resolved
executor/window.go Outdated Show resolved Hide resolved
@codecov-io
Copy link

codecov-io commented Jan 7, 2019

Codecov Report

Merging #8899 into master will increase coverage by 0.01%.
The diff coverage is 63.73%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8899      +/-   ##
==========================================
+ Coverage   67.14%   67.16%   +0.01%     
==========================================
  Files         371      372       +1     
  Lines       76515    76642     +127     
==========================================
+ Hits        51379    51477      +98     
- Misses      20546    20558      +12     
- Partials     4590     4607      +17
Impacted Files Coverage Δ
planner/core/logical_plans.go 73.72% <ø> (ø) ⬆️
planner/core/physical_plans.go 60.86% <ø> (ø) ⬆️
expression/aggregation/base_func.go 40.9% <0%> (-9.1%) ⬇️
executor/aggregate.go 75.89% <100%> (+0.2%) ⬆️
planner/core/exhaust_physical_plans.go 92.16% <100%> (+0.06%) ⬆️
util/chunk/chunk.go 82.62% <100%> (+0.12%) ⬆️
planner/core/rule_eliminate_projection.go 95.83% <100%> (+0.07%) ⬆️
planner/core/rule_column_pruning.go 91.35% <100%> (+0.09%) ⬆️
planner/core/rule_build_proj_below_agg.go 93.75% <100%> (+9.65%) ⬆️
planner/core/resolve_indices.go 54.08% <60%> (+0.5%) ⬆️
... and 11 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f18e034...85f4efe. Read the comment docs.

Copy link
Member

@winoros winoros left a comment

Choose a reason for hiding this comment

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

No mem tracker currently?

@alivxxx
Copy link
Contributor Author

alivxxx commented Jan 8, 2019

@winoros Yes, we can add it latter.

@alivxxx
Copy link
Contributor Author

alivxxx commented Jan 9, 2019

PTAL @zz-jason @eurekaka @winoros

executor/window.go Outdated Show resolved Hide resolved
executor/window.go Outdated Show resolved Hide resolved
executor/window.go Show resolved Hide resolved
executor/window.go Outdated Show resolved Hide resolved
executor/window.go Outdated Show resolved Hide resolved
executor/window.go Outdated Show resolved Hide resolved
return errors.Trace(err)
}

childResult := e.children[0].newFirstChunk()
Copy link
Member

Choose a reason for hiding this comment

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

should we allocate a Chunk with tidb_max_chunk_size capacity?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

tidb_max_chunk_size may result in unnecessary results.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, to avoid unnecessary results, we should use a smaller chunk size for the first Chunk used to fetch child result. But in the next time, we should use a bigger chunk size. This function always use newFirstChunk() to fetch the child result, it's not efficient for big tables.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I tried the way mentioned in the comment, currently, we need to call chunk.Renew to create a larger chunk, and it requires to remember the last chunk... Maybe we can refine it after we can pass down the chunk size to the child.

Copy link
Member

Choose a reason for hiding this comment

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

Okay.

Copy link
Member

Choose a reason for hiding this comment

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

Could you file an issue to trace this problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, #9045

executor/window.go Outdated Show resolved Hide resolved
return errors.Trace(err)
}

childResult := e.children[0].newFirstChunk()
Copy link
Member

Choose a reason for hiding this comment

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

Yeah, to avoid unnecessary results, we should use a smaller chunk size for the first Chunk used to fetch child result. But in the next time, we should use a bigger chunk size. This function always use newFirstChunk() to fetch the child result, it's not efficient for big tables.

util/chunk/chunk.go Outdated Show resolved Hide resolved
Copy link
Member

@zz-jason zz-jason left a comment

Choose a reason for hiding this comment

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

LGTM

@zz-jason zz-jason added the status/LGT1 Indicates that a PR has LGTM 1. label Jan 14, 2019
@zz-jason
Copy link
Member

/run-all-tests

@zz-jason
Copy link
Member

@XuHuaiyu @eurekaka PTAL

@alivxxx
Copy link
Contributor Author

alivxxx commented Jan 14, 2019

/run-all-tests

eurekaka
eurekaka previously approved these changes Jan 15, 2019
Copy link
Contributor

@eurekaka eurekaka left a comment

Choose a reason for hiding this comment

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

LGTM

@eurekaka eurekaka added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Jan 15, 2019
@alivxxx
Copy link
Contributor Author

alivxxx commented Jan 15, 2019

PTAL @eurekaka, I resolved the conflicts.

@eurekaka eurekaka merged commit 3835bef into pingcap:master Jan 15, 2019
@alivxxx alivxxx deleted the windowexec branch January 15, 2019 07:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/execution SIG execution status/LGT2 Indicates that a PR has LGTM 2. type/enhancement The issue or PR belongs to an enhancement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants