From: | Mark Phillips <mark(dot)phillips(at)mophilly(dot)com> |
---|---|
To: | Adam Brusselback <adambrusselback(at)gmail(dot)com> |
Cc: | Christopher Browne <cbbrowne(at)gmail(dot)com>, Christophe Pettus <xof(at)thebuild(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: serial + db key, or guid? |
Date: | 2020-08-15 19:14:29 |
Message-ID: | BDB25EC2-1A3E-4411-8E97-07A283880994@mophilly.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks to everyone who replied. All helpful. I learned and have new ideas to work with.
> On Aug 11, 2020, at 10:42 AM, Adam Brusselback <adambrusselback(at)gmail(dot)com> wrote:
>
> I mentioned this in another email thread yesterday about a similar topic, but I'd highly suggest if you do go the UUID route, do not use the standard UUID generation functions, they all suck for database use (v1 also sucks).
>
> I use: https://pgxn.org/dist/sequential_uuids/ <https://pgxn.org/dist/sequential_uuids/> written by Thomas Vondara (writeup here: https://2ndquadrant.com/en/blog/sequential-uuid-generators/ <https://2ndquadrant.com/en/blog/sequential-uuid-generators/> )
>
> I don't mind having a time component correlated with my UUID's because it's simply not a threat model that matters for my use case, so I use the time based variant. It helped me immensely with FPW and
> write amplification when I switched from V4 UUIDs. It is still not as fast as an int, but it is much much better than random UUIDs.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-08-15 19:17:03 | Re: pg_basebackup + delta base backups |
Previous Message | Ayub M | 2020-08-15 12:47:56 | Re: hash joins are causing no space left error |