estimateRgEndOffset slop calculation is insufficient for incompressible data
@thexiay ya está trabajando en esto.
Desde el 7/5/2026.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 78/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Tranquilo
- Stack tecnológico
- java
- Área
- data-engineering
Línea de trabajo
Abre RecordReaderUtils.java y empieza en estimateRgEndOffset; después, sigue el cálculo del tamaño de la ejecución DIRECT de RLEv2 utilizado para la estimación de lectura anticipada. Verifica el caso de datos incomprimibles con bufferSize 1024, incluido el encabezado de 2 bytes; se considera terminado cuando el cálculo permite seis bloques y ya no alcanza la excepción de tamaño de búfer indicada.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
The estimateRgEndOffset method in RecordReaderUtils.java uses a stretchFactor to estimate how much compressed data to read ahead for a row group. The current formula:
int stretchFactor = 2 + (MAX_VALUES_LENGTH * MAX_BYTE_WIDTH - 1) / bufferSize;
does not account for the 2-byte RLEv2 DIRECT run header. This means the worst-case uncompressed payload is actually MAX_VALUES_LENGTH * MAX_BYTE_WIDTH + 2 bytes (512 * 8 + 2 = 4098), not MAX_VALUES_LENGTH * MAX_BYTE_WIDTH (4096).
Impact
When data is incompressible (e.g., random bytes), each compression block expands to HEADER_SIZE + bufferSize bytes. With bufferSize = 1024, the old formula gives stretchFactor = 5, allocating space for 5 compressed blocks. However, 4098 bytes of uncompressed data requires ceil(4098 / 1024) = 5 blocks of payload, plus the initial 2 blocks from the base factor, totaling 6 blocks needed. The old estimate falls short by one block, causing IllegalArgumentException: Buffer size too small when reading a full RLE v2 DIRECT run at the estimated boundary.
Fix
Include the RLEv2 header size in the worst-case calculation:
int maxRleDirectRunSize = MAX_VALUES_LENGTH * MAX_BYTE_WIDTH + 2;
int stretchFactor = 2 + (maxRleDirectRunSize - 1) / bufferSize;
This correctly yields stretchFactor = 6 for bufferSize = 1024, ensuring enough space is allocated.
- Lenguaje dominante
- Java
- Estrellas
- 769
- Forks
- 515
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/orc
-
[C++] Reader cannot resolve Java fixed-offset writer timezone IDs such as GMT-00:00Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
-
cross compileAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
Todos los issues de apache/orc
Issues similares
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
waiting-for-triage
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
spring-cloud/spring-cloud-openfeign#1443 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 84/100
ADORSYS-GIS/keycloak-oid4vp-plugin#221 ·
Los mantenedores suelen responder en 2 días
-
Upgrade to Spring Pulsar 2.0.8Abiertostatus: team-only type: dependency-upgrade
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
spring-projects/spring-boot#52099 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
tchiotludo/akhq#3307 · 1 reacción ·
Los mantenedores suelen responder en 1 día