-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
plan: make query on partition table not cacheable #16375
Conversation
b0be604
to
e9b48cf
Compare
Codecov Report
@@ Coverage Diff @@
## master #16375 +/- ##
===========================================
Coverage 80.3928% 80.3928%
===========================================
Files 506 506
Lines 137103 137103
===========================================
Hits 110221 110221
Misses 18285 18285
Partials 8597 8597 |
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.
Have you figure out why there is a cast
and is that evitable?
If there is no better way, I think this one is an acceptable solution.
} | ||
return in, false | ||
} | ||
|
||
func (checker *cacheableChecker) isPartitionTable(tn *ast.TableName) bool { | ||
tb, err := checker.schema.TableByName(tn.Schema, tn.Name) |
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 change may have some performance impact.
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.
Why would this PR incur significant performance regression? it just adds one more check for TableName.
Because of the check here. @eurekaka
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.
Are those 2 map lookups so expensive?
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.
schema.TableByName() is O(N)
operation.
And the cacheableChecker
itself need to handle each tableName in the AST.
/sysbench |
@XuHuaiyu PTAL |
LGTM |
/bench |
Benchmark Report
@@ Benchmark Diff @@
================================================================================
--- tidb: 22664a706f093adcff82bffab6ca7367add314b7
+++ tidb: 14f8ccc72380267879103443e7743e665ba85c00
tikv: 7d13ca02374582bd7714d3298efb74909d69ca64
pd: 878ac7e830af195912603501d5d4de8ccffff232
================================================================================
oltp_update_index:
* QPS: 4235.82 ± 4.34% (std=129.44) delta: 2.13% (p=0.384)
* Latency p50: 30.24 ± 4.38% (std=0.92) delta: -2.06%
* Latency p99: 55.11 ± 5.01% (std=1.91) delta: -4.83%
oltp_read_write:
* QPS: 14106.59 ± 1.30% (std=128.84) delta: 0.82% (p=0.226)
* Latency p50: 181.84 ± 1.35% (std=1.69) delta: -0.82%
* Latency p99: 345.67 ± 2.24% (std=5.14) delta: -0.74%
oltp_point_select:
* QPS: 39013.27 ± 0.42% (std=117.78) delta: -2.93% (p=0.221)
* Latency p50: 3.28 ± 0.41% (std=0.01) delta: 2.24%
* Latency p99: 11.14 ± 2.76% (std=0.23) delta: -0.87%
oltp_update_non_index:
* QPS: 8854.25 ± 0.41% (std=25.87) delta: 0.06% (p=0.367)
* Latency p50: 14.45 ± 0.42% (std=0.04) delta: -0.09%
* Latency p99: 29.54 ± 1.20% (std=0.25) delta: -0.16%
|
PTAL @zz-jason |
14f8ccc
to
2a1bc90
Compare
it's seems this pr bring performance impact that can not be ignore. |
What's your opinion? @XuHuaiyu |
/run-all-tests |
Why would this PR incur significant performance regression? it just adds one more check for |
@imtbkcat merge failed. |
/run-all-tests |
/run-common-test |
/merge |
/run-all-tests |
cherry pick to release-4.0 in PR #16723 |
/run-cherry-picker |
Signed-off-by: sre-bot <sre-bot@pingcap.com>
cherry pick to release-3.0 in PR #16759 |
Signed-off-by: sre-bot <sre-bot@pingcap.com>
cherry pick to release-3.1 in PR #16760 |
What problem does this PR solve?
Issue Number: close #16364
Problem Summary:
#15697 will check whether plan is a query on partition table and will pass by if is true. But there is still some problems bring by
stmtCtx.UseCache
. If a plan isCacheable
,stmtCtx.UseCache
is set totrue
. So thesimpleRewriter
has different output compare with not cached plan.For example, in #16364. If prepare-plan-cache is on, although query on partition table is not cached, it has different plan.
not use cache:
lt(test.employees.id, 3)
use cache:
lt(cast(test.employees.id), 3)
this small change in
rewriter
cause partition pruning fail.What is changed and how it works?
Proposal: xxx
What's Changed:
add partition check in
Cacheable
function rather thangetPhysicalPlan
Related changes
Check List
Tests
Side effects
Release note