zanmato1984 commented on issue #45393:
URL: https://github.com/apache/arrow/issues/45393#issuecomment-2628993132
Sorry I'm on vacation and unable to get on to it now. From what I see in the
benchmark report, it's possible that #45336 is related (TPCH Q3 has heavy joins
and aggregations, both in the code path that PR touched). And it's also
possible that the new answer is correct (meaning the old passes are false
positives) - if I'm interpreting the the report right:
```
' old$o_shippriority | new$o_shippriority \n'
' [1] 2330369 - 0 [1] \n'
' [2] 3466209 - 0 [2] \n'
' [3] 497024 - 0 [3] \n'
' [4] 1190661 - 0 [4] \n'
' [5] 2439265 - 0 [5] \n'
' [6] 5112866 - 0 [6] \n'
' [7] 5526083 - 0 [7] \n'
' [8] 2630758 - 0 [8] \n'
' [9] 997703 - 0 [9] \n'
'[10] 2307653 - 0 [10]\n'
'\n'}]
```
Note column `o_shippriority` should be all `0` in a valid TPCH Q3 result.
And the old values very much look like column `o_orderkey`. This could imply
something changing in the column decoding. But these are all wild guesses for
now.
I think I can look into it in about two weeks. But in the meantime, it'll be
nice if some people familiar with these benchmarks (R?) can help to confirm my
assumption ("the old result of `o_shippriority` being
non-zero/`o_orderkey`/`l_orderkey`"). Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
