4 ms·

I think as far as number types, you NEED (in the you should be considered seriously broken even if you can hobble along without) to have: - a 64-bit float - a

I think as far as number types, you NEED (in the you should be considered seriously broken even if you can hobble along without) to have: - a 64-bit float - a 64-bit int everything else can be emulated in code from there and you can play all the encoding games you want to save space when you don't have to use it. This covers 99.999% of the use cases you reasonably see. From there, I would argue, you should also have: - a bit and byte - 32-bit ints - 32-bit float - 128-bit int (once you add UUIDs you might as well make them full numerics citizens). If I were doing a modern database, I'd have the kitchen sink as a type full numerics from 8 to 128 bit both signed and unsigned int and all supported hardware float sizes. I'd probably even have a 512-bit AVX type just to see what people would use it for.

Dylan16807 10y ago
Why do you NEED a 64 bit int? Why not 32 bit? You're not storing pointers in a database. (And then you can implement your 32 bit int in terms of the 53 bits of int-capacity in a double.)
- jnordwick 10y ago
  datetimes, aggregations, etc. pretty much anything non-toy in the modern world requires 64 bit int. like I said. read NEED as in you can certainly hobble around without it (pick an appropriate offset and read your 53 bits in relation to it), but like a fracture in a leg, it's still considered broken.
  - Dylan16807 10y ago
    What exactly do you mean by aggregations here? If you want a good timestamp you probably want a timespec, and that won't fit in 64 bits anyway. I don't see why it's easy to make 128+ bit types be composite, but you can't have 64 bit types be composite. Your database driver can take care of how the bits are packed on the wire. It really shouldn't be a big concern.
    - jnordwick 10y ago
      probably easier to have this convo in email (check my profile). HN iisn't quite setup for back and forth. I'm more than willing to see your point about about a 53-bit int. I think dev experience can be made more difficult as long as a you get compensation in other areas. Email me a "hi" and I'll respond, but it might have to wait until later in the day.
    - SamReidHughes 10y ago
      A query optimizer might do a lot better with a native integer type than a user-defined one cobbled out of int32's. It knows all the mathematical properties of the type and add things in any order, knows that x < y implies x + 1 <= y, etc.
- StreamBright 10y ago
  Because I want to store something that is a 64bit int? I mean this is really a weird question. There are a lot of things that require this starting with timestamps: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
  - Dylan16807 10y ago
    Which you can store as two 32 bit integers, or one 53 bit integer. Nothing requires native 64 bit. 64 bit is nicer than 32 bit, but it's scarcely more necessary than 128 bit numbers.

Dylan16807 10y ago

Why do you NEED a 64 bit int? Why not 32 bit? You're not storing pointers in a database. (And then you can implement your 32 bit int in terms of the 53 bits of int-capacity in a double.)

jnordwick 10y ago
datetimes, aggregations, etc. pretty much anything non-toy in the modern world requires 64 bit int. like I said. read NEED as in you can certainly hobble around without it (pick an appropriate offset and read your 53 bits in relation to it), but like a fracture in a leg, it's still considered broken.
- Dylan16807 10y ago
  What exactly do you mean by aggregations here? If you want a good timestamp you probably want a timespec, and that won't fit in 64 bits anyway. I don't see why it's easy to make 128+ bit types be composite, but you can't have 64 bit types be composite. Your database driver can take care of how the bits are packed on the wire. It really shouldn't be a big concern.
  - jnordwick 10y ago
    probably easier to have this convo in email (check my profile). HN iisn't quite setup for back and forth. I'm more than willing to see your point about about a 53-bit int. I think dev experience can be made more difficult as long as a you get compensation in other areas. Email me a "hi" and I'll respond, but it might have to wait until later in the day.
  - SamReidHughes 10y ago
    A query optimizer might do a lot better with a native integer type than a user-defined one cobbled out of int32's. It knows all the mathematical properties of the type and add things in any order, knows that x < y implies x + 1 <= y, etc.
StreamBright 10y ago
Because I want to store something that is a 64bit int? I mean this is really a weird question. There are a lot of things that require this starting with timestamps: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- Dylan16807 10y ago
  Which you can store as two 32 bit integers, or one 53 bit integer. Nothing requires native 64 bit. 64 bit is nicer than 32 bit, but it's scarcely more necessary than 128 bit numbers.