2010YOUY01 commented on code in PR #13540:
URL: https://github.com/apache/datafusion/pull/13540#discussion_r1855221140
##########
datafusion/physical-plan/src/memory.rs:
##########
@@ -365,8 +365,165 @@ impl RecordBatchStream for MemoryStream {
}
}
+pub trait StreamingBatchGenerator: Send + Sync + fmt::Debug + fmt::Display {
+ /// Generate the next batch, return `None` when no more batches are
available
+ fn generate_next_batch(&mut self) -> Result<Option<RecordBatch>>;
+
+ /// Creates a boxed clone of this generator.
+ ///
+ /// This method is required because `Clone` cannot be directly implemented
for
+ /// trait objects. It provides a way to clone trait objects of
+ /// StreamingBatchGenerator while maintaining proper type erasure.
+ fn clone_box(&self) -> Box<dyn StreamingBatchGenerator>;
+}
+
+/// Execution plan for streaming in-memory batches of data
+///
+/// This plan generates output batches lazily, it doesn't have to buffer all
batches
+/// in memory up front (compared to `MemoryExec`), thus consuming constant
memory.
+pub struct StreamingMemoryExec {
+ /// Schema representing the data
+ schema: SchemaRef,
+ /// Functions to generate batches for each partition
+ batch_generators: Vec<Box<dyn StreamingBatchGenerator>>,
+ /// Total number of rows to generate for statistics
+ cache: PlanProperties,
+}
+
+impl StreamingMemoryExec {
+ /// Create a new streaming memory execution plan
+ pub fn try_new(
+ schema: SchemaRef,
+ generators: Vec<Box<dyn StreamingBatchGenerator>>,
+ ) -> Result<Self> {
+ let cache = PlanProperties::new(
+ EquivalenceProperties::new(Arc::clone(&schema)),
+ Partitioning::RoundRobinBatch(generators.len()),
Review Comment:
Is this field mean: Let's say a exec only have 1 generator, the optimizer
will try to insert a `RepartitionExec` to the output of `StreamingMemoryExec`,
and use round robin to repartition output batches to `target_partitions` number?
I found it works on some aggregate queries, but not for a sort query
```
> explain select * from generate_series(1, 10000) as t1(v1) order by v1;
+---------------+----------------------------------------------------------------------------------------------------------------+
| plan_type | plan
|
+---------------+----------------------------------------------------------------------------------------------------------------+
| logical_plan | Sort: t1.v1 ASC NULLS LAST
|
| | SubqueryAlias: t1
|
| | Projection: tmp_table.value AS v1
|
| | TableScan: tmp_table projection=[value]
|
| physical_plan | SortExec: expr=[v1@0 ASC NULLS LAST],
preserve_partitioning=[false] |
| | ProjectionExec: expr=[value@0 as v1]
|
| | StreamingMemoryExec: partitions=1,
batch_generators=[generate_series: start=1, end=10000, batch_size=8192] |
| |
|
+---------------+----------------------------------------------------------------------------------------------------------------+
```
Parallelized sort should look like
```
> explain select * from lineitem order by l_orderkey;
+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| plan_type | plan
|
+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| logical_plan | Sort: lineitem.l_orderkey ASC NULLS LAST
|
| | TableScan: lineitem projection=[l_orderkey, l_partkey,
l_suppkey, l_linenumber, l_quantity, l_extendedprice, l_discount, l_tax,
l_returnflag, l_linestatus, l_shipdate, l_commitdate, l_receiptdate,
l_shipinstruct, l_shipmode, l_comment]
|
| physical_plan | SortPreservingMergeExec: [l_orderkey@0 ASC NULLS LAST]
|
| | SortExec: expr=[l_orderkey@0 ASC NULLS LAST],
preserve_partitioning=[true]
|
| | ParquetExec: file_groups={14 groups:
[[Users/yongting/Code/datafusion/benchmarks/data/tpch_sf1/lineitem/part-0.parquet:0..11525426],
[Users/yongting/Code/datafusion/benchmarks/data/tpch_sf1/lineitem/part-0.parquet:11525426..20311205,
Users/yongting/Code/datafusion/benchmarks/data/tpch_sf1/lineitem/part-1.parquet:0..2739647],
[Users/yongting/Code/datafusion/benchmarks/data/tpch_sf1/lineitem/part-1.parquet:2739647..14265073],
[Users/yongting/Code/datafusion/benchmarks/data/tpch_sf1/lineitem/part-1.parquet:14265073..20193593,
Users/yongting/Code/datafusion/benchmarks/data/tpch_sf1/lineitem/part-2.parquet:0..5596906],
[Users/yongting/Code/datafusion/benchmarks/data/tpch_sf1/lineitem/part-2.parquet:5596906..17122332],
...]}, projection=[l_orderkey, l_partkey, l_suppkey, l_linenumber, l_quantity,
l_extendedprice, l_discount, l_tax, l_returnflag, l_linestatus, l_shipdate,
l_commitdate, l_receiptdate, l_shipinstruct, l_shipmode, l_comment] |
| |
|
+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
```
I want to know is it correct here, and this sort query in theory can be made
parallelized by changing somewhere in optimization phase? 🤔
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
