Dennis Bjørn Christensen
05/22/2026, 1:51 PMpsutil to snapshot NIC bytes before/after `DoGet`:
• Arrow table in memory:129 MB (100K rows, XML-heavy column)
• Bytes received on NIC:141 MB(the 9% overhead could be gRPC/HTTP2 framing?)
• Compression ratio:0.91x, so, no compression applied
We tried both grpc-encoding: gzip per-call header and grpc.default_compression_algorithm = 2 as a channel option. Neither changed the wire size.
Looking at: be/src/service/service_be/arrow_flight_sql_service.cpp the DoGetStatement returns:
return std::make_unique<arrow::flight::RecordBatchStream>(reader);
The second parameter (IpcWriteOptions) is omitted, so Arrow defaults to codec = nullptr (no compression).
FE-side FlightServer.builder also has no .compressor() set, so gRPC-level compression is not negotiated either.
Questions
1. Is Arrow Flight compression on the roadmap?
2. Is there a server-side config we've missed that enables it?
3. If not currently supported, is a feature request the right path? The fix appears to be "just" passing`IpcWriteOptions`with a codec to`RecordBatchStream`.Rocky
05/22/2026, 1:51 PMbe.conf, fe.conf) or session variables that enable compression for Arrow Flight SQL.
* gRPC-level compression: As you noted, setting grpc-encoding at the client/channel level does not work because the StarRocks implementation does not currently negotiate or utilize gRPC-level compressors for the Flight service.
* IPC-level compression: The code in arrow_flight_sql_service.cpp indeed initializes the RecordBatchStream using default IpcWriteOptions, which defaults to uncompressed output.
3. Is a feature request the right path?
Yes. Creating a feature request on the StarRocks GitHub repository is the correct path.
Your technical assessment is spot-on: the implementation change involves passing an IpcWriteOptions object with a specified compression codec (like LZ4_FRAME or ZSTD) to the RecordBatchStream constructor.
Recommended next steps:
* Open a GitHub Issue: Submit a feature request referencing your findings. Mention that for high-latency or bandwidth-constrained environments, the 0.9x "compression" ratio (uncompressed overhead) is a bottleneck.
* Community Contribution: Since you have already identified the specific code location (be/src/service/service_be/arrow_flight_sql_service.cpp), you might consider submitting a Pull Request. Adding a session variable (e.g., arrow_flight_compression_codec) to control this would be the standard StarRocks approach for such a feature.
Note that while Arrow Flight is designed for high performance, StarRocks' current implementation prioritizes the "zero-copy" path. Compression adds a CPU-bound serialization step that may offset gains in high-bandwidth environments, which is likely why it wasn't enabled by default in the initial release.
References
• unloading/arrow_flight.md
• administration/management/BE_configuration.md
• loading/loading_introduction/feature-support-loading-and-unloading.mdDennis Bjørn Christensen
05/26/2026, 8:29 AM