From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | Mark Phillips <mark(dot)phillips(at)mophilly(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: serial + db key, or guid? |
Date: | 2020-08-11 16:40:44 |
Message-ID: | 6544D62C-3FF4-46B2-BD5F-845B9AD70B31@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Aug 11, 2020, at 09:37, Mark Phillips <mark(dot)phillips(at)mophilly(dot)com> wrote:
>
> I posed the question on the chance things had evolved since 2012, specifically as it relates to postgres.
The essentials haven't changed. Keys (such as UUIDs, especially UUID v4) that have most of their randomness in the most significant bits can cause significant cache hit problems on large indexes. 128 bit keys are usually overkill for most applications, unless you need actual *global* uniqueness across more than a single database or installation; 64 bit keys are usually sufficient.
UUIDs (and similar very large random keys) do have the advantage that they are somewhat self-secure: You can expose them to outsiders without having to worry about other keys being guessable.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2020-08-11 17:01:54 | Re: serial + db key, or guid? |
Previous Message | Mark Phillips | 2020-08-11 16:37:53 | Re: serial + db key, or guid? |