3 ms·
A million rows is quite small. A string will use 36 bytes per row. bigserial will use 8 bytes per row. At 4 billion rows that's about 100G. Now imagine a row w
by arp242 2y ago
A million rows is quite small.
A string will use 36 bytes per row. bigserial will use 8 bytes per row. At 4 billion rows that's about 100G. Now imagine a row with 3 foreign keys to other tables with string UUIDs and you're wasting 300G (vs UUID type) or 400G (vs. bigserial), for no good reason. And doing things like "where id = ?" will be slower. You will be able to keep fewer rows cached in memory. Etc.
It's absolutely not a bikeshed. And migrating all of this later on can be a right pain so it's worth getting it right up-frong.
It's also not more effort to do things right: usually it's exactly the same effort as doing it wrong.
- groestl 2y ago> And migrating all of this later on can be a right pain so it's worth getting it right up-frong I've never had to move from uuids to integers. I've had to move from integers to uuids plenty of times though.
- arp242 2y agoI've migrated tables to more compact formats. Inefficient storage is the sort of of thing that works fine for a lot of things, right up to the point where you're running out of disk space or memory and it's no longer fine. I'm not against UUIDs nor saying you should optimize everything, I'm just saying you should think about things, and that thinking about things really isn't that time-consuming or that much effort.