Eric Fu

> There are two cases: > > 1. the root fragment is simply a single distribution exchange operator. It will be scheduled at the frontend. > 2. the root fragment...

> For 2.2 I would suggest to add a singleton exchange on top of table scan so that all three cases can be executed in same way, and we don't...

> updates come in batches of 1 or 2. Same question. Can this be solved by turning the checkpoint interval larger?

> I guess the point is that executors should not wait for an input chunk to be fully processed before processing the next input chunk, if CPU is idle. Yes,...

> > In another words, the quick messages do not help to improve the latency of barriers. > > > > Actually, I disagree here. > > > > Consider...

> > a later packet/fetch may be received first, but we can just put it in the queue until all its prior packet done > > Yes, but actually, all...

> > In another word, only `insert` messages (without any delete/update event between them) are reorderable? > > Actually, no, invidivual insert, delete, update can be reordered as long as...

This feature will facilitate the performance test of streaming operators, by eliminating the cost of Source Executor. Hope it can be done.

@TennyZhuang Can you do it recently? Or reassign?

> This feature will facilitate the performance test of streaming operators, by eliminating the cost of Source Executor. Hope it can be done. To clarify, this feature is nice-to-have but...