UUID vs Bigint Battle!!! | Scaling Postgres 302
To get the show notes as well as get notified of new episodes, visit:
www.scalingpostgres.com/episo...
In this episode of Scaling Postgres, we discuss when and how you should use UUIDs or not, how to optimize space with column order and arrays, whether it is better to tune parameters or queries and what devs should know about Postgres with Andrew Atkinson.
Want to learn more about Postgres performance?
Join my FREE mini-course called the PostgreSQL Performance Starter Kit here: www.scalingpostgres.com/cours...
Timestamps:
00:00 - Postgres Performance Demystified Webinar
00:34 - UUID Benchmark War
03:22 - UUID in Postgres: PgSQLPhriday #015
04:16 - PGSQL Phriday #015: Primary keys: UUID, CUID, or TSID?
05:02 - Postgres.AI bot interview for PGSQL Phriday #015
05:36 - Reducing table size with optimal column ordering and array-based storage
06:59 - Tuning Parameters vs Tuning Queries: presentation and recording
07:48 - What Developers Should Know About Postgres With Andrew Atkinson | Rubber Duck Dev Show 114
08:25 - Modern SQL
09:24 - Postgres again elected DBMS of the Year in 2023, but I'm worried
10:20 - PostgreSQL is Enough Gist
11:11 - Podcast highlights on benchmarking Postgres performance, from Path To Citus Con Episode 11
11:26 - Benchmarking Postgres Vector Search approaches: Pgvector vs Lantern
12:00 - Pgvector vs Lantern part 2 - The one with parallel indexes
12:16 - Contemplating Decentralized Extension Publishing
12:54 - Outro
#postgres #postgresql
Пікірлер: 7
My thoughts on UUIDs is that they're primarily useful for anonymization and data protection, but this means they aren't primary keys or even stored in the same table. Each different application should receive a different UUID in order to prevent data linking/mining.
i was shocked when i saw picture of Erwin on lukas's youtube cover :)
I love this new catchphrase I found: "They will do something radically different and then iterate their way back to how things were before." UUID was radically different from an sequential number and when it turned out to be slow and huge they started making it smaller and less random and now it's basically a timestamp with some random stuff attached.
@ScalingPostgres
3 ай бұрын
"All that was old is new again." In the case of a fully random UUID, I bet some devs have been thinking, oh boy we probably should not have done that.
@DylanYoung
3 ай бұрын
You should read the article about reimplementing relational databases in python to improve their dictionary implementation. It's hilarious. IIRC it was Martin Hedegger.
Where can I find the link for your webinar?
@ScalingPostgres
3 ай бұрын
Here is a direct link for it: www.scalingpostgres.com/webinars/postgres-performance-demystified/