Investigate numpy-array-like Arrow view to avoid the scatter copy
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ó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/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ệ
- numpy, python, sqlalchemy
- Lĩnh vực
- backend, performance
Hướng nghiên cứu
Start by reading SQLBackendArray._raw_getitem and the eager aggregation path, then review the _array_like contract in xarray/core/variable.py referenced in the issue. Prototype an adapter for float64 PyArrow arrays and compare the copy and round-trip behavior. Done means the prototype shows whether the scatter copy can be avoided and how indexing and .chunk() behave.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
SQLBackendArray._raw_getitem and the eager aggregation path both copy PyArrow RecordBatch columns into a preallocated numpy buffer (one read pass per batch column). The copy is necessary today because PyArrow buffers are immutable views and numpy needs a writable buffer.
xarray.Variable does not strictly require a numpy ndarray; it accepts anything that meets the _array_like contract (see xarray/core/variable.py#L373). If we can wrap a pyarrow.Array in a tiny adapter that satisfies that contract, the scatter step becomes a pointer assignment and the round-trip skips a full read pass.
Open questions:
- Do we need contiguous storage per dim, or can we hand xarray a list of
pyarrow.Arraychunks with a custom__array__that materializes lazily? - How does indexing (slicing, fancy indexing) compose with the adapter once xarray asks for sub-views?
- Does this play nicely with the chunked / dask path users will reach for after
.chunk()?
Worth prototyping on a single dtype family first (float64) to see if the adapter shape is even tractable.
Spun out of #167.
- 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ự
-
comp/cli P3 type/security
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
NousResearch/hermes-agent#141420 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
vendor-pitch
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 87/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug llm p2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
New tool: ZIPZAX Python Notebook StudioCó thể đã có người làm @github-actions đã nhận hôm nay. Đang mởsubmission triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
kausalflow/tools#226 · 1 bình luận ·
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 82/100