colexec: fix AND and OR projections in some cases #42129
Conversation
|
This change is |
There was a problem hiding this comment.
Interesting. Can you repro this with a filter on a non-indexed column before an AND? This probably needs a backport, right?
This seems like it could be a bug that could be easily introduced in any kind of operator. I wonder if there's a way that we could have caught this automatically.
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @asubiotto)
Previously, the original batch length was not respected when the selection vector is present. This resulted in, for example, query 19 of TPCH benchmark to return an error. This is now fixed. I have troubles coming up with a reduced reproduction though. Release note: None
|
I spent some more time trying to reproduce it, but I didn't succeed. I think in order to trigger this problem you need 1. several batches (i.e. it will not trigger on the first one) and 2. the length of the second batch be shorter than the first one and that that second batch has an interesting selection vector. I feel like it's not worth spending more time trying to come up with a repro. Yes, it will need to be backported. |
yuzefovich
force-pushed
the
fix-and-proj
branch
from
ab8d7da to
0a9eb56
Compare
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1.
Reviewable status:
|
TFTR! bors r+ |
37583: storage: Migrate MVCCStats.contains_estimates from bool to int64 r=tbg a=giorgosp This migration allows ContainsEstimates to be reset after a stats recomputation (by returning a -ContainsEstimates delta) without worrying about a race condition. Another command may add 1 to it flag and it will still be stored as valid. Resolves #37120 Release note: None 42129: colexec: fix AND and OR projections in some cases r=yuzefovich a=yuzefovich Previously, the original batch length was not respected when the selection vector is present. This resulted in, for example, query 19 of TPCH benchmark to return an error. This is now fixed. I have troubles coming up with a reduced reproduction though. I also checked that on release-19.2 branch the query is executed correctly with vectorized, so it must be the switch to flat bytes that triggers the problem. Release note: None 42172: colexec: fix sorted distinct with nulls behavior r=yuzefovich a=yuzefovich Previously, sorted distinct when the nulls might be present would always get the value at the index without paying attention whether that value is actually now. This is incorrect behavior because it is undefined in some cases (like when getting from flat bytes). Now this is fixed. Fixes: #42055. Release note: None Co-authored-by: George Papadrosou <[email protected]> Co-authored-by: Yahor Yuzefovich <[email protected]>
Build succeeded |
Previously, the original batch length was not respected when the
selection vector is present. This resulted in, for example, query 19 of
TPCH benchmark to return an error. This is now fixed.
I have troubles coming up with a reduced reproduction though.
I also checked that on release-19.2 branch the query is executed
correctly with vectorized, so it must be the switch to flat bytes that
triggers the problem.
Release note: None