clintropolis opened a new pull request, #17391: URL: https://github.com/apache/druid/pull/17391
This PR is a follow-up to #16863 to fix a problem for any complex metrics which do not specify the byte order of the underlying buffer and were counting on the java big endian default (such as `approxHistogram`). The underlying `CompressedBlockReader` already had the ability to specify an order on the buffer for values it reads, but it was just specifying the same order that the compression was using, which is native order by default for performance reasons. To push this into the block reader, I have added `ObjectStrategy.getByteOrder()` with a default implementation returning big endian, though it probably would have been safe to hard-code to use big endian, since the things that need little endian were already explicitly ordering stuff on value read. However, thinking forward it seems like it would be nice to not have to re-order the values again in the object strategy if we can know ahead of time. I have added implementations for `ObjectStrategy` which i knew were little endian, even though they are already explicitly ordering values on read due to the behavior of the uncompressed complex columns. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
