4 ms·

That would be true except for that fact that database designers know this, and offer a way to generate sequential GUID's; so it's actually not a problem for tha

That would be true except for that fact that database designers know this, and offer a way to generate sequential GUID's; so it's actually not a problem for that reason. The only real downside is performance, an int key performs better.

dhd415 11y ago
Every sequential GUID generation feature provides guarantees only per session. In other words, when you bring your database down to upgrade or patch it and then bring it back up, your GUID sequence starts over again at some arbitrary value which is likely to overlap with your existing GUIDs.
- gnaritas 11y ago
  > your GUID sequence starts over again at some arbitrary value which is likely to overlap with your existing GUIDs. I don't believe that's true. You're right that they start the session over, but it'll still be a fresh sequence that doesn't overlap anything generated in the past.
jsmthrowaway 11y ago
> an int key performs better. A UUID is a 128-bit integer. That people do not store, generate, or interact with them that way is the bug. I'd kill for a 128-bit architecture so a UUID compare would be a single instruction, and it's too bad consensus is that we don't really need it.
- gnaritas 11y ago
  An int is either 4 or 8 bytes, it's still going to perform better no matter how you treat the GUID. edit: bytes
  - jandrese 11y ago
    I hope you mean bytes. On a 128bit architecture that would be a single instruction compare, just like a 32 or 64 bit compare. Performance would be roughly the same (minus maybe a cache miss because you blew it out with your fat ints).
  - jessedhillon 11y ago
    > An int is either 4 or 8 bits This perfectly summarizes the bitwise-innumeracy of the argument against UUIDs. Even without 128 bit word sizes, most UUIDs are going to be non-matches in their lower bits, assuming a random distribution. There's no computational efficiency gained in the vastly wide critical path here.
    - deleted 11y ago
      [deleted]
    - gnaritas 11y ago
      > most UUIDs are going to be non-matches in their lower bits, assuming a random distribution But you can't assume a random distribution because anyone using UUID's for database keys isn't using random UUID's, they're using sequential ones.
      - jsmthrowaway 11y ago
        Which would still make the low-order quadword not match.
        gnaritas 11y ago
        It's a database though, you don't get to control how comparisons are done. Guid's are larger than ints, so using them as keys or joining on them is going to be slightly slower (not that it makes them bad, I'm not against GUID's). Just as using a bigint will be slower than an int.
        jsmthrowaway 11y ago
        If I were implementing the uuid type in Postgres and did anything other than `if(unlikely(LO(uuid1) == LO(uuid2)) && unlikely(HI(uuid1) == HI(uuid2)))` I'd consider myself doing the wrong thing, personally. Two 64-bit compares, two flag checks, and a branch, which is about as fast as it's going to get in the absence of a 128-bit architecture. You could actually vectorize the compares in SSE, I believe (but I stopped writing assembly before SSE existed and don't know much about it at a low level). This is why it's so critical to treat a UUID as an integer instead of a string, and I see a lot of code that does the latter.
- mortehu 11y ago
  > I'd kill for a 128-bit architecture so a UUID compare would be a single instruction Well, there's PCMPESTRI on Intel. http://www.felixcloutier.com/x86/PCMPESTRI.html http://www.felixcloutier.com/x86/PCMPESTRI.html
  - jsmthrowaway 11y ago
    Yeah, I just said this in another comment, but SSE is my weak point; I stopped writing assembly and dealing with this stuff before SSE was even introduced. That looks basically like what you need, though, yeah. Cool.
mvitorino 11y ago
A number of scenarios that require UUIDs as keys, involve generation client side where such guarantees may not be available. In my view, UUIDs should not be used unless there is a strong reason for it (such as making keys not guessable). Most people will implement them incorrectly/inefficiently.

dhd415 11y ago

Every sequential GUID generation feature provides guarantees only per session. In other words, when you bring your database down to upgrade or patch it and then bring it back up, your GUID sequence starts over again at some arbitrary value which is likely to overlap with your existing GUIDs.

gnaritas 11y ago
> your GUID sequence starts over again at some arbitrary value which is likely to overlap with your existing GUIDs. I don't believe that's true. You're right that they start the session over, but it'll still be a fresh sequence that doesn't overlap anything generated in the past.

jsmthrowaway 11y ago

> an int key performs better. A UUID is a 128-bit integer. That people do not store, generate, or interact with them that way is the bug. I'd kill for a 128-bit architecture so a UUID compare would be a single instruction, and it's too bad consensus is that we don't really need it.

gnaritas 11y ago
An int is either 4 or 8 bytes, it's still going to perform better no matter how you treat the GUID. edit: bytes
- jandrese 11y ago
  I hope you mean bytes. On a 128bit architecture that would be a single instruction compare, just like a 32 or 64 bit compare. Performance would be roughly the same (minus maybe a cache miss because you blew it out with your fat ints).
- jessedhillon 11y ago
  > An int is either 4 or 8 bits This perfectly summarizes the bitwise-innumeracy of the argument against UUIDs. Even without 128 bit word sizes, most UUIDs are going to be non-matches in their lower bits, assuming a random distribution. There's no computational efficiency gained in the vastly wide critical path here.
  - deleted 11y ago
    [deleted]
  - gnaritas 11y ago
    > most UUIDs are going to be non-matches in their lower bits, assuming a random distribution But you can't assume a random distribution because anyone using UUID's for database keys isn't using random UUID's, they're using sequential ones.
    - jsmthrowaway 11y ago
      Which would still make the low-order quadword not match.
      - gnaritas 11y ago
        It's a database though, you don't get to control how comparisons are done. Guid's are larger than ints, so using them as keys or joining on them is going to be slightly slower (not that it makes them bad, I'm not against GUID's). Just as using a bigint will be slower than an int.
        jsmthrowaway 11y ago
        If I were implementing the uuid type in Postgres and did anything other than `if(unlikely(LO(uuid1) == LO(uuid2)) && unlikely(HI(uuid1) == HI(uuid2)))` I'd consider myself doing the wrong thing, personally. Two 64-bit compares, two flag checks, and a branch, which is about as fast as it's going to get in the absence of a 128-bit architecture. You could actually vectorize the compares in SSE, I believe (but I stopped writing assembly before SSE existed and don't know much about it at a low level). This is why it's so critical to treat a UUID as an integer instead of a string, and I see a lot of code that does the latter.
mortehu 11y ago
> I'd kill for a 128-bit architecture so a UUID compare would be a single instruction Well, there's PCMPESTRI on Intel. http://www.felixcloutier.com/x86/PCMPESTRI.html http://www.felixcloutier.com/x86/PCMPESTRI.html
- jsmthrowaway 11y ago
  Yeah, I just said this in another comment, but SSE is my weak point; I stopped writing assembly and dealing with this stuff before SSE was even introduced. That looks basically like what you need, though, yeah. Cool.

mvitorino 11y ago

A number of scenarios that require UUIDs as keys, involve generation client side where such guarantees may not be available. In my view, UUIDs should not be used unless there is a strong reason for it (such as making keys not guessable). Most people will implement them incorrectly/inefficiently.