Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

`RequiresFallback.isCompressionSatisfying` is too aggressive with current default page size

Đang mở
  • Có gì không ổn?
#3,479 1 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@yadavay-amzn đang làm issue này rồi.

Từ ngày 11/5/2026.

Đá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
45/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ệ
java
Lĩnh vực
data-engineering

Hướng nghiên cứu

Bắt đầu tại điểm vào RequiresFallback.isCompressionSatisfying và theo dõi cách các chỉ mục trang, giá trị mặc định 20,000 hàng và dictionary fallback tương tác với nhau. So sánh các kết quả được báo cáo với 20,000 hàng và 128,000 hàng, sau đó xác định liệu thay đổi đã thống nhất là một heuristic lấy mẫu được sửa đổi hay một tùy chọn cấu hình; được xem là hoàn tất khi hành vi này được bao phủ đối với dữ liệu có lực lượng bản ghi ở mức vừa phải.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Type: enhancement
Describe the enhancement requested

An issue recently was brought up in arrow-rs (https://github.com/apache/arrow-rs/pull/9700) which brought to my attention the existence of isCompressionSatisfying in the RequiresFallback interface. In short, after accumulating a page worth of data, isCompressionSatisfying is called to see if dictionary encoding is actually compressing the data at all, and if not, then the encoder falls back immediately to the fallback encoder. As far as I could determine, this behavior was introduced very early on, before the advent of the page indexes, so IIRC the page size would have been significantly larger. With page indexes, however, this function is now called after only 20000 rows have been processed. A column with a moderate cardinality might not yet have produced enough repeating values to lead this function to conclude it's best to continue using a dictionary.

For example, a dataframe with an int64 column consisting of one million values mod'd with 32768 will end up ditching dictionary encoding completely, and produce a column chunk of 8.4MB. If the page row count is bumped up to 128k, then dictionary encoding is used throughout and the resultant column chunk is only 2.2MB.

Sadly, it does not appear that this behavior is configurable, so short of increasing the page row count, its behavior cannot be modified.

I can see the need for this type of heuristic, but I think it needs to be modified in light of the current defaults resulting in far too few samples with which to determine if dictionary encoding is beneficial or not. If collecting more samples before falling back is not practical, there should at least be a configuration setting to disable this check.

Component(s)

Core

Ngôn ngữ chính
Java
Star
3.1k
Fork
1.6k
Merge trung bình
4 ngày 5 giờ
Pull request đã merge (30 ngày)
30

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/parquet-java

Tất cả issue của apache/parquet-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.