6 ms·
One thing I don’t see being mentioned in this thread (I only skimmed the article, so I don’t know if it’s mentioned there) is that you can run out of numbers wh
by PestoDiRucola 4y ago
One thing I don’t see being mentioned in this thread (I only skimmed the article, so I don’t know if it’s mentioned there) is that you can run out of numbers when using serial, as they have a max, so if you are planning to have a table which will have over 2147483647 rows, then you might look into other types to use as a unique identifier.
- aeyes 4y agoJust use biginteger everywhere, still more efficient than even UUIDv4.
- tylergetsay 4y agoFor anyone wondering, this is around 60 records per second for a year before you max out
- arp242 4y agoYou can use bigserial instead of serial, which goes up to 9223372036854775807.
- dspillett 4y agoIf your DB supports unsigned integers, or starting sequences from -2,147,483,648, you can double the address range. But if you are at all worried that you'll get within a couple of orders of magnitude of MAXINT32 in the lifetime of your application then you should immediately jump to 64-bit values. Doubling is often just noise and the cost of refactoring if you approach MAXINT32 much faster than expected is more or a problem than the extra storage cost of bigger keys.
- marcosdumay 4y ago> you can run out of numbers when using serial Yes, that's why you use bigserial.
- PestoDiRucola 4y agoBut the comment I replied to was mentioning serial though.
- badestrand 4y agoI think you can just make that dependent on the table's data. For a table of user posts use bigserial but for a list of companies, prices or names the serial will surely be sufficient.