Refactor I/O exec nodes

[eddyxu]

• Reconstruct the I/O execute node to a more standard physical plan, represented by an ExecNode tree.
• Make the Scan node (leaf node) own the logic of batch read.
• Add Take node that do random reads based on the indices returned from the Filter node.

[changhiskhan]

Do we also need to test that it's not scanning the whole column and returning 6-8? or is that already tested elsewhere?

[eddyxu]

Good point. This one is tested on the decoder, not the "columnar reader“ / ExecNode. It might need mock arrow::RandomAccessFile to verify. Should we do it in a separate PR?

[changhiskhan]

i’m ok with that. Can you make a github issue for that then?

[eddyxu]

Filed #138

[changhiskhan]

would it make sense to use different variable names here instead of reassigning to child? reads a bit confusing here.

[eddyxu]

This one, child is like the head of a linked list. The reason writing in this way is that, there is an optional Limit in between Take and Filter.

Otherwise, the code might look like

filter_node.= Filter::Make()
if (limit) {
   limit_node = Limit::Make(filter_node);
   take_node = Take::Make(limit_node);
} else {
  take_node = Take::Make(filter_node);
}

Any suggestions?

[changhiskhan]

i kind of feel like that makes the logic clearer because it’s more explicit and the cost is only one extra line. I don’t feel super strongly about it so it’s not a blocker.

[eddyxu]

Ok, i can update this. I lean to think the current way is more mathmatically general, i.e., ”inserting one ExecNode to the head of chain", instead of making each ::Make a special case tho.

But I am fine with either way.

[changhiskhan]

let's call this a filter_scan instead of just a plain scan?

[eddyxu]

Do you mean filter_scan_schema?

[changhiskhan]

right, filter_scan_schema instead of scan_schema
and was there also a filter_scan_node instead of scan_node? i forgot

[eddyxu]

will do

[eddyxu]

Rebased to main.

[changhiskhan]

couple of nits remaining