The unsorted paths are better for hash aggregation, but currently in
this case we are only going to add sorted paths.

Add ANALYZE. To keep the desired MergeAppend plans, we also have to add
a LIMIT everywhere so that the MergeAppend is chosen based on its lower
startup cost. Otherwise the plain Sort over Append will be chosen
because for small tables its cost is less.

Add ANALYZE after compression. The plan changes are expected, SeqScans
are preferred over IndexScans and Sort over MergeAppend for small
tables.

We would add extra Sort nodes when adjusting the children of space
partitioning MergeAppend under ChunkAppend. This is not needed because
MergeAppend plans add the required Sort themselves, and in general no
adjustment seems to be required for the MergeAppend children
specifically there.

the CI

This reverts commit f50947e.

This reverts commit e5a660b.

This reverts commit 5ac83d8.

This reverts commit 6a75d46.

Currently we use the cheapest path before final aggregation for this
(i.e. Append over individual chunks), but it does not consider the cost
of a Sort that might be required before aggregation. To account for
this, use instead the child path of the cheapest final aggregated path.