I think it would be useful. As far as I've seen the main costs in carrying data types are in writing performant encoders, and updating integrations to work with them. I'm guessing with 128 bit integers there would be some integrations that can't or won't support it, which might be a cause for confusion. Overall, though, I think the upsides of efficiency and decreased storage space are compelling. Do you have a sense yet of what encodings are going to be supported down the road (will we get to full parity with 32/64)?
- Dan On Thu, Nov 16, 2017 at 2:19 PM, Grant Henke <[email protected]> wrote: > Hi all, > > As a part of adding DECIMAL support to Kudu it was necessary to add > internal support for 128 bit integers. Taking that one step further and > supporting public columns and APIs for 128 bit integers would not be too > much additional work. However, I wanted to gauge the interest from the > community. > > My initial thoughts are that having an INT128 column type could be useful > for things like UUIDs, IPv6 addresses, MD5 hashes and other similar types > of data. > > Is there any interest or uses for a INT128 column type? Is anyone > currently using a STRING or BINARY column for 128 bit data? > > Thank you, > Grant > -- > Grant Henke > Software Engineer | Cloudera > [email protected] | twitter.com/gchenke | linkedin.com/in/granthenke >
