From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Primary keys and composite unique keys(basic question) |
Date: | 2021-04-06 02:37:09 |
Message-ID: | 8ECC2031-7B0F-4765-B8B2-5B8047B06DA3@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
> It's a small thing, but UUIDs are absolutely not memorizable by
> humans; they have zero semantic value. Sequential numeric identifiers
> are generally easier to transpose and the value gives some clues to
> its age (of course, in security contexts this can be a downside).
>
I take the above as a definite plus. Spent too much of my life correcting others’ use of “remembered” id’s that just happened to perfectly match the wrong thing.
> Performance-wise, UUIDS are absolutely horrible for data at scale as
> Tom rightly points out. Everything is randomized, just awful. There
> are some alternate implementations of UUID that mitigate this but I've
> never seen them used in the wild in actual code.
>
That b-tree’s have been optimized to handle serial ints might be a considered a reaction to that popular (and distasteful) choice. Perhaps there should be a ’non-optimized’ option.
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2021-04-06 02:53:03 | Re: Primary keys and composite unique keys(basic question) |
Previous Message | Merlin Moncure | 2021-04-06 02:17:14 | Re: Primary keys and composite unique keys(basic question) |