General ART improvements and memory pressure reduction

[taniabogatsch]

This PR combines several changes to the ART and mainly focuses on reducing its memory pressure during index creation (CREATE INDEX). Combining these changes significantly improves ART creation performance and its memory footprint.

Memory pressure reduction

Disable sorting for VARCHAR and compound keys

Before this PR, we always add a sorting operator to the pipeline preceding the index creation operator. Especially for VARCHAR keys and compound keys, this sorting operation significantly blew up the memory.

Now, we check the key types during plan creation. If we detect a VARCHAR or compound key type, we adjust the pipeline accordingly, i.e., we do not add that sorting operator.

This change has implications for the execution of the create index operator, which previously expected its incoming data to be sorted. We now have to distinguish between the sorted and not sorted cases and only execute the old (faster) Sink implementation on sorted data. This is still desirable since the regression in performance is negligible, and the memory pressure decreases significantly. For not sorted data, we now insert the keys key-at-a-time into the thread-local ART of a sink.

ARTs can now share their memory

Each thread has its local ART. We build a chunk-sized ART with an efficient construction strategy that does not require iterating all keys for every incoming chunk of sorted data. We then merge that chunk-sized ART into the thread-local ART. This merging step is very efficient since all operations are on sorted data.

Before this PR, the chunk-sized ART would allocate its own memory, which would then get appended to the thread-local ART's memory. This significantly blows up the memory, as we preallocate blocks of 256KB.

This PR allows ARTs to share their memory. Consequently, the thread-local ART can now share its memory with the chunk-sized ART, decreasing memory pressure.

Performance improvements

Tree structures such as the ART make it tempting to use recursion for simplicity. For specific scenarios, such as many duplicate keys, or very long prefixes, using recursion for some functions can become problematic. The recursion depth incurs significant overhead in function calls.

Therefore, this PR changes some function implementations from recursive to iterative ones (for Leaf and Prefix).

• Changed functions: Free, Vacuum, Deserialize, Serialize

Benchmarks

I also want to show some benchmark numbers, to highlight the positive effect of the reduction in memory pressure on performance. All the benchmarks can be found in benchmark/micro/index/create/.

Benchmark	info	master branch	PR
create_art_varchar.benchmark	28.8M VARCHAR, 7.2M distinct, 8GB memory limit	time-out, oom	11.39
create_art.benchmark	10M INT64, 2.5M distinct	0.56	0.22
create_art_varchar_long.benchmark	10M long VARCHAR	0.23	0.19
create_art_varchar_short.benchmark	10M short VARCHAR	0.15	0.13
create_art_random.benchmark	10M INT, approx. 1M distinct	0.51	0.18
create_art_duplicates.benchmark	10M INT, approx. 100 distinct	bus error	0.20

Other improvements

• added a benchmark on VARCHAR index creation with a memory limit to detect regression on the memory consumption
• fixed ART benchmarks for DELETE and INSERT operations
• move Vacuum to the Finalize step of the index creation operation. This is now possible because the thread-local ARTs share their memory.

This PR also closes the following issues.

• Close create index causes SIGBUS (Misaligned address error) on MacARM #8066
• Close CREATE INDEX ends in out of memory error #7760
• Close Avoid excessively calling vacuum during concurrent index operations #7406

[pdet]

Tania, great PR! Thanks for it!

I just had some small code nips, and a couple questions about one of the tests!

[Mytherin]

Thanks! LGTM