Batching and re-build the chunk in the exchange receiver to avoid too low selectivity visibility bitmap

[st1page]

proposed by @fuyufjh

Currently, our stream exchange highly depends on chunk's visibility bitmap. In the sender side, the chunk is cloned into each dispatcher and then each dispatcher eliminates the rows not belong to the downstream shard.

risingwave/src/stream/src/executor/dispatch.rs

Line 808 in 7f6dd61

StreamChunk::with_visibility(ops.clone(), chunk.columns().into(), vis_map);

So supposing there are N parallelisms of the downstream fragment, the selectivity of the visibility bitmap would be 1/N.
And on the Receiver side, it will receive these two kind of chunk

• compacted chunk with low cardinality(chunk_size/N) from the remote shuffle
• chunk with low selectivity visibility bitmap (1/N)

They are both not friendly to our vectorized processing engine

[lmatz]

Is it possible that we rearrange/rebuild the rows in the chunk before exchange and group rows that belong to the downstream consecutive with each other?

Then, on the receiver side, we don't compact and still get chunk with low selectivity visibility bitmap,
but the following operator still gets the benefit of vectorized processing as it only needs to process a consecutive range of rows.

[st1page]

Is it possible that we rearrange/rebuild the rows in the chunk before exchange and group rows that belong to the downstream consecutive with each other?

Then, on the receiver side, we don't compact and still get chunk with low selectivity visibility bitmap, but the following operator still gets the benefit of vectorized processing as it only needs to process a consecutive range of rows.

But what is the advantage comparing with rebuilding in the receiver side 🤔 Their overhead are both one more copy and construct the chunk

[lmatz]

But what is the advantage comparing with rebuilding in the receiver side

each receiver side needs to rebuild once vs just rebuild once on the sender side

Edit:
I see, there is batching step on the receiver side, so it can be amortized

[st1page]

Update: rebuild the chunk in any case will make the nexmark performance degrade #16055

[github-actions]

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean.
Don't worry if you think the issue is still valuable to continue in the future.
It's searchable and can be reopened when it's time. 😄

[st1page]

#17968