alamb commented on code in PR #26035:
URL: https://github.com/apache/datafusion/pull/26035#discussion_r4243116709
##########
datafusion/substrait/src/logical_plan/producer/rel/fetch_rel.rs:
##########
@@ -26,29 +26,28 @@ pub fn from_limit(
producer: &mut impl SubstraitProducer,
limit: &Limit,
) -> datafusion::common::Result<Box<Rel>> {
- let input = producer.handle_plan(limit.input.as_ref())?;
+ // Pushing down LIMIT + OFFSET can produce a scan fetch above i64::MAX.
Review Comment:
i64::MAX is pretty large -- 9,223,372,036,854,775,807
What is the usecase for a query that skips / offsets that many?
In other words I question if we need special case handling for fetch/offset
##########
datafusion/substrait/tests/cases/roundtrip_logical_plan.rs:
##########
@@ -320,6 +320,205 @@ async fn select_without_limit() -> Result<()> {
roundtrip_fill_na("SELECT * FROM data OFFSET 5+7-2").await
}
+#[tokio::test]
+async fn roundtrip_table_scan_offset_and_fetch() -> Result<()> {
+ use datafusion::arrow::array::Int64Array;
+ use datafusion::dataframe::DataFrame;
+ use datafusion::datasource::provider_as_source;
+ use datafusion::logical_expr::TableScanBuilder;
+
+ // A single CSV partition preserves input order and supports exact skip
pushdown.
+ let temp = tempfile::tempdir()?;
+ let path = temp.path().join("data.csv");
+ std::fs::write(&path, "x\n0\n1\n2\n3\n4\n5\n")?;
+ let ctx = SessionContext::new();
+ ctx.register_csv("t", path.to_str().unwrap(), CsvReadOptions::new())
+ .await?;
+ let source = provider_as_source(ctx.table_provider("t").await?);
+
+ for skip in [Some(2), None, Some(0), Some(8)] {
+ for fetch in [None, Some(0), Some(2)] {
+ for project in [false, true] {
+ for parent in [
+ None,
+ Some((0, Some(2))),
+ Some((1, Some(3))),
+ Some((1, None)),
+ ] {
+ let scan = TableScanBuilder::new("t", source.clone())
+ .with_skip(skip)
+ .with_fetch(fetch)
+ .build()?;
+ let mut builder =
+ LogicalPlanBuilder::from(LogicalPlan::TableScan(scan));
+ if project {
+ builder = builder.project(vec![col("x")])?;
+ }
+ if let Some((skip, fetch)) = parent {
+ builder = builder.limit(skip, fetch)?;
+ }
+ let plan = builder.build()?;
+ let proto = to_substrait_plan(&plan, &ctx.state())?;
+ let restored = from_substrait_plan(&ctx.state(),
&proto).await?;
+ let mut expected = (0_i64..6)
+ .skip(skip.unwrap_or(0))
+ .take(fetch.unwrap_or(usize::MAX))
+ .collect::<Vec<_>>();
+ if let Some((skip, fetch)) = parent {
+ expected = expected
+ .into_iter()
+ .skip(skip)
+ .take(fetch.unwrap_or(usize::MAX))
+ .collect();
+ }
+ for (stage, plan) in [("original", plan), ("roundtrip",
restored)] {
+ let batches = DataFrame::new(ctx.state(),
plan).collect().await?;
+ let actual = batches
+ .iter()
+ .flat_map(|batch| {
+ batch
+ .column(0)
+ .as_any()
+ .downcast_ref::<Int64Array>()
+ .unwrap()
+ .values()
+ .iter()
+ .copied()
+ })
+ .collect::<Vec<_>>();
+ assert_eq!(
+ actual, expected,
+ "{stage}: skip={skip:?}, fetch={fetch:?},
project={project}, parent={parent:?}"
+ );
+ }
+ }
+ }
+ }
+ }
+ Ok(())
+}
+
+// Limit expressions use Int64, but limit pushdown can produce a larger usize
fetch.
Review Comment:
this feels to me like it is unnecessary (again for a i64 max ...) I think it
would be better just to error if the limit/offset overflowed i64::MAX and we
can fix it after if we find a real usecase
--
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]
