-
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
projection containing virtual columns should be evaluated before the UnionScan(dirty write content) #53951
Comments
If we check the execution plans, it looks fine:
The data in the transaction buffer should be read by the
In this case, we have |
Thinking about how to solve this issue, but:
|
Update: The Projection is used to prune the 'base column' of virtual generated column generated from The codes shown in 'buildUnionScanFromReader' is old and vulnerable, in order to avoid the potential risks, we decide to report errors(instead of return wrong results) when facing 'unknown' executors: #53956. To solve this bug in a short term, we prevent pushing Projection with VGC down to UnionScan in #53981, because it might lead to plans like |
hi, @bb7133, what effect (if any) does preventing projection propagation have on performance? would it mean that more data might need to be shuttled through some layers inside TiDB/TiKV? if there are queries that select only "smaller" columns in a "large" row and use VGC in the where clause, would their performance worsen (because there are larger disk reads or more data to shuttle, etc)? |
/found customer |
The fix will not cause performance problems currently. But, yes, we'll get a better performance if the projection can be calculated at the TiKV side when the transaction has un-committed data and if the projection has json related functions. TiDB has some simple column pruning tech when reading data from TiKV even if no projection is pushed to TiKV. |
/found customer |
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
2. What did you expect to see? (Required)
No result was returned because we updated
is_deleted
in the transaction.3. What did you see instead (Required)
The update in the transaction was not read.
4. What is your TiDB version? (Required)
It exists in all versions of TiDB.
The text was updated successfully, but these errors were encountered: