Praveen Kumar Desabandu created ARROW-5164:
--
Summary: [Gandiva] [C++] Introduce 32bit hash functions
Key: ARROW-5164
URL: https://issues.apache.org/jira/browse/ARROW-5164
Project: Apache Arrow
Rok Mihevc created ARROW-5165:
-
Summary: [Python][Documentation] Build docs don't suggest
assigning $ARROW_BUILD_TYPE
Key: ARROW-5165
URL: https://issues.apache.org/jira/browse/ARROW-5165
Project: Apache
Marco Neumann created ARROW-5166:
Summary: [Python] Statistics for uint64 columns may overflow
Key: ARROW-5166
URL: https://issues.apache.org/jira/browse/ARROW-5166
Project: Apache Arrow
Issu
Definitely prefer option 1.
I'm a -0.5 on the change in general. I think that early on users may want
to pattern things this way but as you start trying to parallelize work,
pipeline work, etc, moving beyond moderate batch sizes is ultimately a
different use case and won't be supported well within
Lawrence Chan created ARROW-5167:
Summary: Upgrade string-view-light to latest
Key: ARROW-5167
URL: https://issues.apache.org/jira/browse/ARROW-5167
Project: Apache Arrow
Issue Type: Bug
Hi Jacques,
I think there are different use cases. What we are seeing now in many
places is the desire to use the Arrow format to represent very large
on-disk datasets (eg memory-mapped). If we don't support this use case it
will continue to cause tension in adoption and result in some application
Hey Wes,
I appreciate your comments and want to be clear that I am not blocking this
addition.
Memory mapping itself is not in conflict with my comments. However, since
Arrow datasets do not exist frequently on disk today, a user can make
choices as to whether to use smaller or larger batches. Wh
Yosuke Shiro created ARROW-5168:
---
Summary: [GLib] Add garrow_array_take()
Key: ARROW-5168
URL: https://issues.apache.org/jira/browse/ARROW-5168
Project: Apache Arrow
Issue Type: New Feature
