Idea: Avoid planning CoalesceBatches in front of blocking operators.

[ctsk]

The blocking operators (HJ buid side, Aggregation) are often planned on top of a RepartitionExec with a CoalesceBatchesExec in-between. However, one of the first things these operators do is concatenate the freshly coalesced batches - Maybe there is no benefit from adding the coalesce's here?

I've prototyped an implementation here: #15479

[ctsk]

One downside: Increased memory usage.

The hash join build side stores the RecordBatches in a vector before building the hash table. This vector will grow larger. In addition, we might delay e.g. garbage collection for StringViews, which also increases memory usage.

[Dandandan]

One downside: Increased memory usage.

The hash join build side stores the RecordBatches in a vector before building the hash table. This vector will grow larger. In addition, we might delay e.g. garbage collection for StringViews, which also increases memory usage.

Perhaps instead of removing the coalescebatches, we can change the the threshold ratio to be much smaller (e.g. 1/10th (or something based on some benchmarkig) of the size instead of 1/2). That way the overhead of Vec is minimal while probably still redundant copying in many cases.