fixed group by int16 and Date types on AMD EPYC 7401P machine #3512
Conversation
| @@ -1475,7 +1475,9 @@ void NO_INLINE Aggregator::mergeDataImpl( | |||
| Table & table_src, | |||
| Arena * arena) const | |||
| { | |||
| for (auto it = table_src.begin(); it != table_src.end(); ++it) | |||
There was a problem hiding this comment.
On the last cycle iteration, calculation of the table_src.end() becomes extremely slow(up to 1s) . for template parameters [with Method = DB::AggregationMethodOneNumber<short unsigned int, HashMapTable<long unsigned int, HashMapCell<long unsigned int, char*, TrivialHash, HashTableNoState>, TrivialHash, HashTableFixedGrower<16>, Allocator<true> > >; Table = HashMapTable<long unsigned int, HashMapCell<long unsigned int, char*, TrivialHash, HashTableNoState>, TrivialHash, HashTableFixedGrower<16>, Allocator<true> >] . Such strange behavior is not reproduced on Intel desktop machines. (On Xeon we did not test this) and on other data types.
There was a problem hiding this comment.
I could provide branch with logs and they output, because such behavior is really strange for me.
dbms/src/Interpreters/Aggregator.cpp
Outdated
| for (auto it = table_src.begin(); it != table_src.end(); ++it) | ||
| decltype(table_src.end()) end = table_src.end(); | ||
|
|
||
| for (auto it = table_src.begin(); it != end; ++it) |
There was a problem hiding this comment.
You can write
for (auto it = table_src.begin(), end = table_src.end(); it != end; ++it)
for more convenience.
|
Yes, really strange. Also it's strange that it is calculated on every interation. |
|
I have successfully reproduced this issue. |
|
I have no sudo on the server with AMD EPYC, will wait... |
|
It would be great to find out the root cause |
|
I have merged this PR, but we need to investigate further, this is TODO. |
There is sever performance degradation on AMD EPYC 7401P based systems. Every query with grouping by int16 or Date type becomes very slow (see: #3490).