Performance improvements for UDDSketch

[feikesteenbergen]

Performance tweaks for uddsketch rollup.

When profiling some of our queries (using perf or Instruments) it
was clear that there was a hot piece of code on merge_sketch.
commit 5da4ab2 addresses this.

After addressing this the HashEntry calls was quite high in the profile and with commit f010516 we were able to reduce the runtime by roughly another half.

Dummy data set improvements

For a 600MB data set, with 300k rows, grouped into 3100 buckets, with a dataset
that is fully prewarmed in shared_buffers, and work_mem being high enough
to prevent on-disk sorts, these are some results:

kind	allocations	time needed	mem pct	time pct
baseline (no rollup)*	2713 kB	215.248 ms
baseline (with rollup)	8218825 kB	5887.086 ms	100.0 %	100.0 %
tweak merge_sketch	1286316 kB	2157.163 ms	15.7 %	36.6 %
tweak entry()	1209574 kB	1143.912 ms	14.7 %	19.4 %
introduce entry_upsert()	1285968 kB	1032.128 ms	15.6 %	17.5 %

Some production data set, 1.5 million records, buckets = 1984:

kind	allocations	time needed	mem pct	time pct
baseline (no rollup)*	26891 kB	3206.245 ms
baseline (with rollup)	62747020 kB	66543.369 ms	100.0 %	100.0 %
tweak entry()	23245638 kB	15875.682 ms	37.0 %	23.9 %
introduce entry_upsert()	23245642 kB	13829.614 ms	37.0 %	20.8 %

Same production data set, 1.5 million records, buckets = 186277:

kind	allocations	time needed	mem pct	time pct
baseline (no rollup)*	26731096 kB	7499.256 ms
baseline (with rollup)	73056871 kB	68607.422 ms	100.0 %	100.0 %
tweak entry()	52589861 kB	33231.835 ms	72.0 %	48.4 %
introduce entry_upsert()	52589399 kB	30150.045 ms	72.0 %	43.9 %

*: Added here to show the theoretical lower limit of the time/memory needed

Optimization: merge UDDSketch using iterators

The previous implementation would create a UDDSketch (with a backing
HashMap) for every possible merge, and then call compact_buckets on
that in order to ensure the number of compactions between the target and
the source were equal.

Profiling this, we found out that in a rollup call of a lot of data,
the compact_buckets was pretty much the main contributor to all the
CPU time.

However, if we merge a different sketch into this sketch, we don't need
to actually compact_buckets all the time, we can directly consume the
keys and counts, and apply some compact_key calls to it.

This prevents a lot of heap allocations, as compact_buckets does a fully
copy of the backing HashMap, and then rebuilding it.

For a particular workload, this reduced the execution time from 30 to 12
seconds.

Change implementation for entry()

Profiling showed that this function is quite the hotspot. By changing
the implementation slightly, instead of walking the tree using the
Linked List, but iterate directly over the values, we improve the
throughput of certain CPU bound queries.

We've seen a reduction in time needed of > 50% for certain rollup
queries.

[sgichohi]

Awesome!

[feikesteenbergen]

There's probaby similar improvements in other parts of the code possible. However, I'd like to merge those kinds of fixes one by one myself.