ART prefix refactor

[taniabogatsch]

This PR refactors the prefix handling of our ART index. Additionally, it fully reworks the iterator code and increases the code coverage of the ART.

Before this PR, there were seven ART nodes. Most of these had an inlined Prefix. That prefix contained a count of 4 bytes, and either 8 bytes of prefix data, or a Node pointer of 8 bytes, so in total 12 bytes.

With this PR, we introduce a new prefix node. This prefix node contains data and a node pointer to a subsequent node. The data consists of Node::PREFIX_SIZE + 1 bytes, of which the first byte is the count of that prefix node, and the other bytes are the prefix data. For prefixes exceeding Node::PREFIX_SIZE, the prefix down to a non-prefix node becomes a chain of prefix nodes, otherwise the prefix is stored in a single prefix node. If there is no prefix, then we directly traverse to the subsequent node.

uint8_t data[Node::PREFIX_SIZE + 1];
Node ptr;

This change has two main benefits.

• In the absence of a prefix, we do not allocate any memory for it.
• It enables us to rework the leaves in a future PR, which take up the majority of the memory of the ART. Due to this PR, leaves no longer contain a prefix. If a leaf only contains one row ID, we can now inline that row ID directly into the Node pointer of the previous node, completely omitting the need for a separate Leaf node. [ART] RowID Leaf node specialization #5365

This PR slightly improves the memory consumption for longer keys and does not regress in the presence of shorter keys. The ART still has a fairly high memory pressure, and the goal is to further decrease this in future PRs.

Workload	Current	Prefix Refactor
10M mostly unique 64bit integers	429.1MB	409.2MB
1M 64bit integers with many duplicates	16.5MB	16.7MB
10M non-inlined strings	1.0GB	866.6MB

Also related to #5865.

[pdet]

This looks very good. I just had a small comment about one of the functions.
In general, the refactored code for the iterator looks much better.
One thing I wonder is if this has any impact on performance, I understand that with this change, our ART is potentially smaller since it won't allocate prefix memory if it's not necessary, but I guess it will increase pointer chasing, especially if every node has a prefix before it.

[taniabogatsch]

That's a fair point! To investigate this possible overhead, I can add some benchmarks for Lookup times, maybe during constraint checking. I should also make some existing benchmarks more complex (less sorted :D), especially during insertions and deletions.

[taniabogatsch]

I will open a separate PR (once the CI passes locally) to refactor the testing and benchmarking of the ART. That also adds a benchmark for Lookup performance to ensure we don't regress.

[taniabogatsch]

@pdet I added more tests and a Lookup performance benchmark in #8055.

[taniabogatsch]

@pdet local benchmark comparison, since the Lookup benchmark is still on feature. So there is no regression; the changes to the prefix increase lookup-performance slightly.

benchmark	feature	PR
lookup	1.806496	1.709860

[pdet]

Thanks for running the benchmarks and adding as regression Tania!

It looks great!

[Mytherin]

Thanks! Looks great