Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: top-n下推不稳定
|
username: h5n1
Update SQL, there are two execution plans, the difference is that top-n is not pushed down to TiKV.
Execution Plan 1:
Top-n is pushed down normally, actrows 3
Execution Plan 2:
Top-n is not pushed down, actrows 10
Even without hints, it can be pushed down. For example, as mentioned earlier, 687 times were not pushed down, but 42 times were pushed down.
Hello, can this be manually reproduced in the MySQL client?
If so, you can create a replayer to see if there are any new findings.
If not, it might be quite mysterious 
Let’s ask the experts at the conference, I currently have no ideas
Pay attention to the plan where topn is not pushed down. Besides topn not being pushed down, there is also a UnionScan operator. This operator is generally used when performing read/write operations within a transaction.
So you can verify it like this to see if the scenario does not use topn pushdown:
|
username: 
|
username: 
|
username: 
|
username: begin
insert some data
update xxx where xxx order by limit 1
rollback
And then execute directly without begin:
update xxx where xxx order by limit 1
If it is this issue, you can raise an issue with us. It seems that the union scan within the transaction did not handle topn pushdown properly.
@h5n1
Create an issue Make it possible to push TopN down cross UnionScan · Issue #46755 · pingcap/tidb · GitHub
And we’ll handle it later.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: 
|
username: