@azat I have already forgotten why do we limit threads here.
I suppose that this is not needed already, because the number of threads is limited by pipeline itself (it shouldn't be more than max streams for every step).

Perf test? (reading small amount of data from a table with large amount of parts)

Sure

@azat I have already forgotten why do we limit threads here.

It had been added in #11114

Quote from the comment to the patch from that PR:

Before this patch pipeline.setMaxThreads() was called with 0 (since
streams.size() == 0, while pipes.size() == 1), which leads that
pipeline.getMaxThreads() returns max_streams.

I suppose that this is not needed already, because the number of threads is limited by pipeline itself (it shouldn't be more than max streams for every step).

Yes, since there is no more deprecated streams (non-processors) in this code.

Perf test? (reading small amount of data from a table with large amount of parts)

@alexey-milovidov FWIW there is a test for this tests/queries/0_stateless/01283_max_threads_simple_query_optimization.sql

@azat tests are ok.
What do you think, do we have other reasons to keep this code?

Waiting for perftests now.

@azat tests are ok.
What do you think, do we have other reasons to keep this code?

Nope, LGTM