Re:Unexpected downsides of UUID keys in PostgreSQL
by egeozcan on Thursday June 22, 2023 @10:35AM
(#36432777)
Hi/Lo algorithm also works fine for most cases
Re:Unexpected downsides of UUID keys in PostgreSQL
by viraptor on Thursday June 22, 2023 @10:13AM
(#36432470)
Or increment by more than you need. If you think you'll only ever have 5 nodes, increment by 20. Lots of space for expansion and in practice you'll hit the datatype limits just a bit earlier - you'd need to work around them anyways.
Re:Unexpected downsides of UUID keys in PostgreSQL
by ilyt on Thursday June 22, 2023 @12:04PM
(#36434290)
IIRC that's what MySQL Galera is doing by default
mysql> CREATE TABLE animals (
-> id MEDIUMINT NOT NULL AUTO_INCREMENT,
-> name CHAR(30) NOT NULL,
-> PRIMARY KEY (id)
-> );
Query OK, 0 rows affected (0.34 sec)
mysql> INSERT INTO animals (name) VALUES
-> ('dog'),('cat'),('penguin'),
-> ('lax'),('whale'),('ostrich');
Query OK, 6 rows affected (0.01 sec)
Records: 6 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM animals;
+----+---------+
| id | name |
+----+---------+
| 3 | dog |
| 6 | cat |
| 9 | penguin |
| 12 | lax |
| 15 | whale |
| 18 | ostrich |
+----+---------+
6 rows in set (0.00 sec)
Re:Unexpected downsides of UUID keys in PostgreSQL
by catlifeonmars on Monday July 03, 2023 @02:22PM
(#36576921)
Oh this is clever! I guess it’s actually very similar conceptually to a vector clock. (In that you have partitioned the space of natural numbers into K countably infinite sequences).
If you wanted to (practically speaking anyway) overcome the requirement that K is known, you could borrow prefix based counting from the p-adics.
Not hyper scale, but good enough for failover or a 3-5 node setup.