ClickHouse/tests/queries/0_stateless/01016_uniqCombined64.sql

-- for small cardinality the 64 bit hash perform worse, but for 1e10:
-- 4 byte hash: 2.8832809652e10
-- 8 byte hash: 0.9998568925e10
-- but hence checking with 1e10 values takes too much time (~45 secs), this
-- test is just to ensure that the result is different (and to document the
-- outcome).

SELECT uniqCombined(number)   FROM numbers(1e7);
SELECT uniqCombined64(number) FROM numbers(1e7);
Introduce uniqCombined64() to get sane results for cardinality > UINT_MAX By default uniqCombined() uses 32-bit hash for all types except String, so this means that you cannot use uniqCombined() with i.e UInt64 and cardinality > UINT_MAX, although you can use uniqCombined(toString()) and this will lead to 64-bit hash, but will not have good performance. So uniqCombined64() had been introduced to fix this. Requires: #7213 2019-10-07 21:44:37 +00:00			`-- for small cardinality the 64 bit hash perform worse, but for 1e10:`
			`-- 4 byte hash: 2.8832809652e10`
			`-- 8 byte hash: 0.9998568925e10`
			`-- but hence checking with 1e10 values takes too much time (~45 secs), this`
			`-- test is just to ensure that the result is different (and to document the`
			`-- outcome).`

Update tests for new numbers(limit) syntax $ gg -e 'numbers(toUInt64' -e 'numbers_mt(toUInt64' \| cut -d: -f1 \| sort -u \| xargs sed -i -E 's#numbers(_mt\|)\(toUInt64\(([^()]*)\)\)#numbers\1(\2)#' 2021-02-10 19:27:14 +00:00			`SELECT uniqCombined(number) FROM numbers(1e7);`
			`SELECT uniqCombined64(number) FROM numbers(1e7);`