postings: use Loser Tree for merge

[bboreham]

Loser Tree is an alternative to Heap for k-way merge. It's faster because it doesn't call Less() and Swap() through dynamic dispatch, and because it stores the value at the front of each sequence so saves calling At() over and over.

Full disclosure: I'm doing a talk about this algorithm at GopherCon next week.

I added a benchmark because none of the existing ones merge enough series to show the difference.
Loser tree does use more memory, but not a lot in the context of PromQL evaluation.

goos: darwin
goarch: arm64
pkg: github.com/prometheus/prometheus/tsdb/index
               │    before     │               after                │
               │    sec/op     │   sec/op     vs base               │
Merge/1-8         228.9n ±  1%   228.8n ± 1%        ~ (p=0.803 n=6)
Merge/10-8        39.84µ ±  1%   11.91µ ± 0%  -70.10% (p=0.002 n=6)
Merge/100-8       912.1µ ±  1%   151.1µ ± 0%  -83.44% (p=0.002 n=6)
Merge/1000-8     12.241m ± 10%   1.675m ± 1%  -86.32% (p=0.002 n=6)
Merge/10000-8    159.59m ±  2%   19.12m ± 1%  -88.02% (p=0.002 n=6)
Merge/100000-8   2781.5m ±  0%   590.4m ± 1%  -78.77% (p=0.002 n=6)

               │     before     │                 after                  │
               │      B/op      │     B/op      vs base                  │
Merge/1-8          0.000 ± 0%       0.000 ± 0%         ~ (p=1.000 n=6) 
Merge/10-8         224.0 ± 0%       720.0 ± 0%  +221.43% (p=0.002 n=6)
Merge/100-8      1.812Ki ± 0%     6.453Ki ± 0%  +256.03% (p=0.002 n=6)
Merge/1000-8     16.06Ki ± 0%     64.08Ki ± 0%  +298.93% (p=0.002 n=6)
Merge/10000-8    160.1Ki ± 0%     632.1Ki ± 0%  +294.89% (p=0.002 n=6)
Merge/100000-8   1.531Mi ± 0%     6.109Mi ± 0%  +298.97% (p=0.002 n=6)

Note change to test - instead of requiring that the data structure is identical to EmptyPostings(), check that calling Next() returns false, which implies it was empty.

[fpetkovski]

Impressive, can't wait for the talk to be online.

[gouthamve]

Hey Bryan, is this ready to merge? There are a few conflicts ;)

We looked at this in our bug scrub.

[bboreham]

Yes it can be merged. I had hoped to get the implementation closer between Loki and Prometheus, but currently there is too much of a performance loss to do that.

Also you might not want to take a dependency on something from my personal account. There are precedents - alecthomas, cespare, dennwc, klauspost.

[bwplotka]

LGTM! Thanks 💪🏽

[yeya24]

Is this change ready to merge? Looking forward to test it

[yeya24]

Hi @bboreham, may I know if you have any benchmark for mergedPostings Seek method? Do we expect to see similar improvements as the provided benchmark

[bboreham]

I don't recall benchmarking Seek specifically in Prometheus.

Some of the queries in BenchmarkRangeQuery do call through Seek, and I seem to remember they are dominated by the behaviour of Seek on the underlying postings. E.g. ListPostings.Seek() always does sort.Search, which is expensive in the case that the value you need is list[1].

[jub0bs]

For information, Bryan's talk is now available at https://www.youtube.com/watch?v=AmLtlXEo4UU