4 ms·
Postgres's concurrency control (https://www.postgresql.org/docs/9.5/static/mvcc.html https://www.postgresql.org/docs/9.5/static/mvcc.html) does fine with many c
by combatentropy 10y ago
Postgres's concurrency control (https://www.postgresql.org/docs/9.5/static/mvcc.html https://www.postgresql.org/docs/9.5/static/mvcc.html) does fine with many clients adding rows with numeric IDs derived from a sequence. In Postgres a sequence is a database object that always returns the number 1 more than the number it last gave someone (This is customizable too, https://www.postgresql.org/docs/9.5/static/sql-createsequence.html https://www.postgresql.org/docs/9.5/static/sql-createsequenc...).
With 64-bit integers (in Postgres, "bigint") then you can have over 9 quintillion rows before you run out of numbers.
UUIDs are for when you have more than one database server that people can write to, and those databases must not share IDs. In many cases this is not a design requirement but a design after too little research.
- davidw 10y agoThese were not 'remote clients' accessing PG directly, but independent computers that were not even on or connected to the network some of the time. > UUIDs are for when you have more than one database server that people can write to, and those databases must not share IDs. Exactly.
- dragonwriter 10y ago> Postgres's concurrency control (https://www.postgresql.org/docs/9.5/static/mvcc.html https://www.postgresql.org/docs/9.5/static/mvcc.html) does fine with many clients adding rows with numeric IDs derived from a sequence. Which is fine for circumstances where a database round trip is acceptable at that point; there's situations where assigning IDs to items is something you want to have happen without database interaction at all.