Optimize large IN filters on integer data types

[raunaqmorarka]

Description

Use a bitset based filter instead of a hash set when the range of
values is narrow enough. We use bitset only when it would occupy
lesser space than the equivalent open hash set.
This is useful for making evaluation of dynamic filter more efficient
as we often collect large integer sets in dynamic filters.

    BenchmarkDynamicPageFilter.filterPages
    (filterSize)   (inputDataSet)  (nonNullsSelectivity)   Mode  Cnt  Before score      After score
             100  INT64_FIXED_32K                    0.2  thrpt   30  446.174 ? 10.598   449.113 ?  5.323 ops/s
            1000  INT64_FIXED_32K                    0.2  thrpt   30  407.625 ?  3.139  1379.767 ? 19.318 ops/s
            5000  INT64_FIXED_32K                    0.2  thrpt   30  426.413 ?  6.485  1254.731 ? 11.685 ops/s

Additional context and related issues

Release notes

(x) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

[lukasz-stec]

lgtm % comments

[lukasz-stec]

For a bitset smaller than the L1 cache size, would it make sense to use bitset even if it uses a little bit more memory?

[raunaqmorarka]

Yes, bitset is indeed faster than open hash set at all L1 cache sizes. However, the gap tends to be much smaller for small sized sets.
I'm also hesitant to increase memory usage because this stuff is unaccounted memory usage. So i'll keep the existing logic for now.

[lukasz-stec]

Did you test smaller ranges than 32K? What ranges do we expect in practice?

[raunaqmorarka]

The 32K here is actually just the range of the input values. Narrowing the input range ensures that bitset will be chosen instead of hashset.
Size of set is determined by filterSize and for that the benchmark params are 100, 1000, 5000

[lukasz-stec]

I was asking basically if we expect in practice smaller than 32k value ranges (max - min)?

[raunaqmorarka]

From what i've seen in benchmarks and other anecdotal cases, the joined columns tend to be dates/times or some kind of unique id or primary key which are usually in a not super-wide range.

[lukasz-stec]

Nice improvement!

[martint]

We have this also in SimplifyContinuousInValues. I would move it to io.trino.type.TypeUtils

[raunaqmorarka]

That method is slightly different, over there we're additionally looking for types where it's possible to get the next consecutive value by just incrementing the underlying long by 1.
I've added a code comment and renamed it to be clearer.

[martint]

This is not guaranteed to pollute the profile. It depends on various factors, such whether it runs just on the interpreter, C1, C2, etc. A better way to do that is to run with JMH's bulk warmup mode.

[raunaqmorarka]

I've made that change, but in practise I'm not finding the JMH's bulk warmup mode to be a better choice.
Using that causes a multi-fold increase in the runtime of the benchmark because it warms up each test permutation for N iterations for each benchmark, whereas what we want is to warm up each test permutation once and then warm N iterations for only the benchmark.
The other way of manually polluting profile may not be guaranteed to work but in practice I have never found it to not work.
On the other hand, the JMH's bulk warmup mode is always so time consuming that I always find myself manually editing the code to remove this and pollute the profile manually to get a JHM result in reasonable amount of time.
And running JMH remotely is not the solution to this problem, it still takes up too much time.