Optimize merge of uniqExact without_key

[nickitat]

Changelog category (leave one):

• Performance Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Parallelized merging of uniqExact states for aggregation without a key, i.e. queries like SELECT uniqExact(number) FROM table. The improvement becomes noticeable when the number of unique keys approaches 10^6.
Also uniq performance is slightly optimized.
This closes #4510.

---

x86:

11.880	2.753	-4.315x	-0.769	0.768	uniq_without_key	26	SELECT uniqExact(number) from numbers_mt(1e8)

arm:

5.777	1.077	-5.36x	-0.814	0.813	uniq_without_key	26	SELECT uniqExact(number) from numbers_mt(1e8)

[nickitat]

AST fuzzer (asan) — #43199

[nickitat]

AST fuzzer (debug) - #42819
AST fuzzer (ubsan) - #42691
Integration tests (tsan) [1/4] - #43169
Stateless tests (release, s3 storage) - 01079_parallel_alter_detach_table_zookeeper doesn't look relevant

[KochetovNicolai]

This can be a dangerous code a bit. If somebody common background I/O pool with 1000 threads, it will add 1000 tasks. let's add at least <= NUM_BUCKETS tasks.

Also, with current implementation we can't share such a pool with a multiple uniq functions.
Maybe it's better to avoid calling wait() at all and handle exceptions in every task separately. (But out ThreadPool interface is not so good for it).

[nickitat]

let's add at least <= NUM_BUCKETS tasks.

ok

Also, with current implementation we can't share such a pool with a multiple uniq functions.

yes, we cannot merge states of two different uniqExact-s simultaneously, but it shouldn't be a problem since we aim to utilise all the threads by the current merge. if we would share, client code would need to manually call wait before destroying states which is also not ideal.

[KochetovNicolai]

I had an idea that probably we can put this 3 flags into Data.
Probably it will make a code a bit more readable. (If it is possible to do).

And maybe we can do it with is_able_to_parallelize_merge flag as well to those Data which support it, like

if (settings->max_threads > 1)
            return createAggregateFunctionUniq<
                ..., AggregateFunctionUniqExactData<..., true /* is_able_to_parallelize_merge>
else
            return createAggregateFunctionUniq<
                ..., AggregateFunctionUniqExactData<..., false /* is_able_to_parallelize_merge>

[nickitat]

also thought about that, looks more accurate

[KochetovNicolai]

I am confused a bit why this code is removed.
Probably it's not used, but may be still helpful for debugging.
I would prefer to do it in a separate pr if possible.

[nickitat]

yeah, let's left it untouched

[KochetovNicolai]

Generally looks ok.