hi Sanjay, You may have seen:
https://github.com/apache/arrow/blob/master/format/Layout.md#byte-order-endianness For big-endian systems, they are free to work with integers with the native byte order, but for the purposes of any memory sharing / IPC / RPC of Arrow memory layout, my understanding is our intention is for big-endian to be byte swapped. Adding byte order / endianness to the Arrow metadata for IPC messaging would add complexity for relatively little benefit. If a big-endian system is using Arrow internally and never needs to interact with another system using Arrow, then the need to byte swap would not be an issue. Does this make sense? It's not a question of whether Arrow "supports" big endian platforms but rather what's considered "native" byte ordering for the purposes of relocating the data structures. If anyone has additional thoughts or if I'm misrepresenting the intent of the spec documents please chime in. Thanks Wes On Mon, Aug 1, 2016 at 9:52 AM, Parth Chandra <par...@apache.org> wrote: > Sorry, please disregard my reply. I misunderstood this to be a question on > the Drill mailing list. > > On Mon, Aug 1, 2016 at 9:50 AM, Parth Chandra <par...@apache.org> wrote: > >> Short answer is no. >> Drill's in memory format assumes little endian and it would be very >> disruptive to have to change that. >> There is a JIRA to fix the Drill client to allow little endian and we >> should fix that, but it is currently low in priority. >> >> >> On Mon, Aug 1, 2016 at 9:27 AM, Sanjay Rao <getsanjay...@live.com> wrote: >> >>> As Apache SPARK supports Big Endian systems. >>> >>> Thanks,Sanjay >> >> >>
