| 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: | Whole Thread | Raw Message | 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) |