[ 
https://issues.apache.org/jira/browse/SPARK-58551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesha S updated SPARK-58551:
------------------------------
    Description: 
Python Data Sources cannot use a query's LIMIT to reduce the work they do.

A {{DataSourceReader}} always plans its full set of partitions and reads at 
Arrow batch granularity (10,000 rows by default), so a {{LIMIT 5}} over a REST 
or database-backed source can still cost many requests or a full extract. The 
reader has no way to learn that the query only needs a few rows, and therefore 
cannot add a {{LIMIT}} clause, set a page size parameter, or plan fewer 
partitions.

JVM DSv2 sources already have this capability through 
{{{}SupportsPushDownLimit{}}}; the Python API exposes only {{pushFilters}} 
(SPARK-51271). This is the limit-pushdown counterpart, alongside SPARK-51713 
for column pruning.
h3. Proposal

Add an optional {{DataSourceReader.pushLimit(limit) -> bool}} method, called 
once during planning before {{partitions()}} and {{{}read(){}}}, returning 
whether the reader will use the limit to read less data. {{PythonScanBuilder}} 
mixes in {{SupportsPushDownLimit}} to drive it.

Gated by a new internal config {{spark.sql.python.limitPushdown.enabled}} 
(default false), mirroring {{{}spark.sql.python.filterPushdown.enabled{}}}, 
since it costs one additional Python worker invocation during planning.

  was:
Python Data Sources cannot use a query's LIMIT to reduce the work they do.

A \{{DataSourceReader}} always plans its full set of partitions and reads at 
Arrow batch
granularity (10,000 rows by default), so a \{{LIMIT 5}} over a REST or 
database-backed source can
still cost many requests or a full extract. The reader has no way to learn that 
the query only
needs a few rows, and therefore cannot add a \{{LIMIT}} clause, set a page size 
parameter, or plan
fewer partitions.

JVM DSv2 sources already have this capability through 
\{{SupportsPushDownLimit}}; the Python API
exposes only \{{pushFilters}} (SPARK-51271). This is the limit-pushdown 
counterpart, alongside
SPARK-51713 for column pruning.

h3. Proposal

Add an optional \{{DataSourceReader.pushLimit(limit) -> bool}} method, called 
once during planning
before \{{partitions()}} and \{{read()}}, returning whether the reader will use 
the limit to read
less data. \{{PythonScanBuilder}} mixes in \{{SupportsPushDownLimit}} to drive 
it.

Gated by a new internal config \{{spark.sql.python.limitPushdown.enabled}} 
(default false),
mirroring \{{spark.sql.python.filterPushdown.enabled}}, since it costs one 
additional Python
worker invocation during planning.


> Python Data Sources Limit Pushdown API
> --------------------------------------
>
>                 Key: SPARK-58551
>                 URL: https://issues.apache.org/jira/browse/SPARK-58551
>             Project: Spark
>          Issue Type: Improvement
>          Components: PySpark
>    Affects Versions: 4.2.0
>            Reporter: Ganesha S
>            Priority: Major
>              Labels: pull-request-available
>
> Python Data Sources cannot use a query's LIMIT to reduce the work they do.
> A {{DataSourceReader}} always plans its full set of partitions and reads at 
> Arrow batch granularity (10,000 rows by default), so a {{LIMIT 5}} over a 
> REST or database-backed source can still cost many requests or a full 
> extract. The reader has no way to learn that the query only needs a few rows, 
> and therefore cannot add a {{LIMIT}} clause, set a page size parameter, or 
> plan fewer partitions.
> JVM DSv2 sources already have this capability through 
> {{{}SupportsPushDownLimit{}}}; the Python API exposes only {{pushFilters}} 
> (SPARK-51271). This is the limit-pushdown counterpart, alongside SPARK-51713 
> for column pruning.
> h3. Proposal
> Add an optional {{DataSourceReader.pushLimit(limit) -> bool}} method, called 
> once during planning before {{partitions()}} and {{{}read(){}}}, returning 
> whether the reader will use the limit to read less data. 
> {{PythonScanBuilder}} mixes in {{SupportsPushDownLimit}} to drive it.
> Gated by a new internal config {{spark.sql.python.limitPushdown.enabled}} 
> (default false), mirroring {{{}spark.sql.python.filterPushdown.enabled{}}}, 
> since it costs one additional Python worker invocation during planning.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to