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
explain: Add joins #3922
explain: Add joins #3922
Conversation
I have improved the examples to be reproducible. |
@SunRunAway, @zz-jason, @TomShawn, PTAL. |
Should the related variables be involved? like |
@SunRunAway I have added this in ad7c61d PTAL. Thx :-) |
@SunRunAway, @zz-jason, @TomShawn, PTAL. |
explain-joins.md
Outdated
|
||
### Runtime Statistics | ||
|
||
If [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) (default: 1GB) is exceeded, TiDB will attempt to use temporary storage provided that `oom-use-tmp-storage=TRUE` (default). This means that the hash table used as part of the hash join is created on disk. Runtime statistics, such as memory usage are visible in the `execution info` of `EXPLAIN ANALYZE`. The following example shows the output of `EXPLAIN ANALYZE` with a 1GB (default) `tidb_mem_quota_query` quota, and a 500MB quota. At 500MB the hash table spills to disk: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that the hash table used as part of the hash join is created on disk.
@SunRunAway please confirm: is the build side data cached in memory spilled to disk or the hash table itself is spilled to disk?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should update https://docs.pingcap.com/tidb/stable/system-variables#tidb_mem_quota_query as well so its a bit clearer what this does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, it is that build side data cached in memory spilled to disk, but we should also consider the spilling for hash table in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's better to clearly describe the current behavior on the document. we can update the document once we spilled hash table to disk.
BTW, for performance reason, it's not recommended to spill hash table to disk. There should be other methods to achieve the same goal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have attempted to clarify this in bcb16dd - PTAL, thx :-)
Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/run-all-tests |
@nullnotnil merge failed. |
Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
cherry pick to release-4.0 in PR #4147 |
Follow-up: TOC |
Signed-off-by: ti-srebot <ti-srebot@pingcap.com> Co-authored-by: Null not nil <67764674+nullnotnil@users.noreply.github.com>
What is changed, added or deleted? (Required)
Fixes pingcap/tidb#18576
This is a followup PR to #3858 - but they can be reviewed independently, and merge out of order.
This PR does not add this page to the TOC. I will only do that once all PRs are merged (this is one ~3-4 followup PRs).
The content here is based on/duplicates query-execution-plan. I will merge all of the replacement pages, and then update query-execution-plan (soon to be called explain-overview) as a last step, and in the same PR which adds this page to the TOC.
Which TiDB version(s) do your changes apply to? (Required)
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?