Fixes #109

This PR adds support for vacuuming deletes within row groups during a checkpoint. The way that this works is that adjacent row groups are merged together if possible by checking if adjacent row groups can be folded into fewer row groups. For example, consider the following row groups with the given number of non-deleted rows:

[1: 60K][2: 40K][3: 50K]

After this PR, the checkpoint will observe that row groups #1 and #2 can be merged together into a single row group, and move the database to the following state:

[1: 100K][2: 50K]

The row groups are re-written with only the valid rows, and the old row groups are dropped, removing the deleted rows from the system and freeing up blocks.

Merges are performed with either 1, 2 or 3 target row groups. We always prefer merging into fewer target row groups as that is cheaper from a performance perspective. That means we need to have at least 25% deletions within adjacent row group before merges are performed and rows are cleaned up automatically. If too few rows are deleted they will not be cleaned up and we will write tombstones as is currently the case.

Merge into one row group (requires >= 50% deleted)

[1: 60K][2: 60K]
->
[1: 120K]

Merge into two row groups (requires >= 33% deleted)

[1: 80K][2: 80K][3: 80K]
->
[1: 120K][2: 120K]

Merge into three row groups (requires >= 25% deleted)

[1: 90K][2: 90K][3: 90K][4: 90K]
->
[1: 120K][2: 120K][3: 120K]

Performance

This PR increases the work that is done during checkpointing significantly when partial deletes are performed. Since checkpointing is currently still single-threaded, performance of large DELETE statements can drop significantly. For example, in this extreme scenario performance drops by a factor of ~15:

DELETE FROM lineitem WHERE l_orderkey%2=0;

The reason for this degradation is that in the old delete code we would only write deleted markers for the deleted rows, whereas in this new extreme scenario we end up rewriting half the table (the non-deleted rows).

On the flip side, because deletes are cleaned up, performance of running queries on the table afterwards is sped up since we no longer need to scan deleted rows when executing queries. Running TPC-H Q1 on the lineitem table after the deletion has the following performance:

The more deletions we run, the worse the performance impact of leaving them around. For example, with the following chain of deletions/insertions we get the following timings:

CALL dbgen(sf=0);
COPY lineitem FROM 'lineitem.parquet';
DELETE FROM lineitem WHERE l_orderkey%2=0;
COPY lineitem FROM 'lineitem.parquet';
DELETE FROM lineitem WHERE l_orderkey%2=0;
COPY lineitem FROM 'lineitem.parquet';
DELETE FROM lineitem WHERE l_orderkey%2=0;
COPY lineitem FROM 'lineitem.parquet';
DELETE FROM lineitem WHERE l_orderkey%2=0;
COPY lineitem FROM 'lineitem.parquet';
DELETE FROM lineitem WHERE l_orderkey%2=0;
COPY lineitem FROM 'lineitem.parquet';
DELETE FROM lineitem WHERE l_orderkey%2=0;

While performance should always drop when cleaning up deletes it is especially problematic now because we are doing single-threaded checkpoints. This should be addressed in a future PR and will greatly alleviate the performance problem here.