Perf: limit pushdown — avoid materializing full partitions for LIMIT queries
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- python
- Lĩnh vực
- data, performance
Hướng nghiên cứu
Start by reading PrunableStreamingTable::scan() and the path that carries the limit through PyArrowStreamPartition into the partition factory; the issue names no file or test. Check how projection is passed as a model, then determine how the factory can stop producing rows at the requested limit. Done means a query such as SELECT * FROM ds LIMIT 10 avoids materializing the full first matching partition.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
The partition factory always materializes the full partition regardless of query:
df = pivot(ds.isel(block)) # always loads all 38.4M rows
For queries like SELECT * FROM ds LIMIT 100, DataFusion applies the limit after the factory produces its batch. The factory receives no signal to stop early.
Currently limit is passed from PrunableStreamingTable::scan() down to DataFusion's StreamingTable, which applies it at the execution-plan level — but only after the factory has already materialized the full partition.
Proposed fix
Pass an optional row limit into the factory (similar to projection pushdown). The scan() method can thread the limit through PyArrowStreamPartition so the factory can stop generating rows once the limit is reached.
def make_stream(projection, limit=None) -> pa.RecordBatchReader:
rows_needed = limit or total_rows
# only materialize up to rows_needed rows
Impact
For ARCO-ERA5, LIMIT 10 currently reads 38.4M rows from the first matching partition. With this fix it would read at most batch_size rows.
Parent: #126
- Ngôn ngữ chính
- Python
- Star
- 142
- Fork
- 19
- Merge trung bình
- 1 ngày 9 giờ
- Pull request đã merge (30 ngày)
- 9
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của xqlsystems/xarray-sql
-
documentation
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 85/100
xqlsystems/xarray-sql#268 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
xqlsystems/xarray-sql#267 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 74/100
xqlsystems/xarray-sql#243 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
publish.yml: the TestPyPI verification step is unreachable (and installs the wrong package name)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
xqlsystems/xarray-sql#242 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
xqlsystems/xarray-sql#237 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của xqlsystems/xarray-sql
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
SublimeText/AdvancedNewFile#211 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Imbad0202/academic-research-skills#987 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add date of request to the UIĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
-
Pull-through from gcr.io returns 500 when pulling using podman/buildahCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởIssue Triage-Needed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
pulp/pulp_container#2581 ·
Maintainer thường phản hồi trong vòng 1 ngày