Use Floyd-Rivest selection algorithm instead of std::partial_sort

[danlark1]

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Changelog category (leave one):

• Performance Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Use Floyd-Rivest algorithm, it should be the best for the ClickHouse use case of partial sorting. Bechmarks are in https://github.com/danlark1/miniselect and here

[alexey-milovidov]

Is it because of unspecified "ties" handling?

[danlark1]

Yep, likely some other tests will also have this issue

[alexey-milovidov]

LGTM

[amosbird]

Can we construct any performance tests to validate this method?

[danlark1]

Can we construct any performance tests to validate this method?

I am happy to add more, however I am pretty sure there are enough queries with ORDER BY LIMIT N in the performance tests. I want to see them first

[danlark1]

@alexey-milovidov any chances ci can go through due to Yandex checks? UPD: Solved by force tests marker

[danlark1]

Perf tests are here. 2.5% win overall for all tests, for desc data the speedup in 1400%, some more representative benchmarks as string_sort showed 15% boost

0.350 | 0.301 | -1.163x | -0.141 | 0.140 | string_sort | 7 | SELECT Referer FROM hits_100m_single ORDER BY Referer LIMIT 300 format Null
0.435 | 0.376 | -1.154x | -0.134 | 0.133 | string_sort | 8 | SELECT Title FROM hits_100m_single ORDER BY Title LIMIT 300 format Null
0.488 | 0.423 | -1.154x | -0.134 | 0.133 | string_sort | 50 | SELECT Title FROM hits_100m_single ORDER BY Title, CounterID LIMIT 300 format Null

[danlark1]

One query became 5-10% slower, 15-20 became significantly faster, up to 20x

SELECT MobilePhoneModel, MobilePhoneModel FROM hits_100m_single ORDER BY MobilePhoneModel, MobilePhoneModel LIMIT 10 FORMAT Null

It is expected as Floyd-Rivest is not performing way faster when there are many equal elements in the array, it might be several percent worse. Other than that everything is really good. I believe somewhen in the future I can fix this issue and we will have even better partial sorting.

[danlark1]

@alexey-milovidov you can merge, the tests from 435f410 are good and after that I fixed the performance test which I checked locally, it should be good