This does not look right. If I understand correctly, the position of Bottom in the hierarchy of types is exactly the opposite to that of Unit: the latter could serve as the "universal base" (like the type Object), whereas the former could be seen as the "universal descendant" (some kind of Null type). In other words, Unit is "anything" and Bottom is "nothing".
It does, and has since its original discovery. Though the effect is not as pronounced as its popular conception would have you believe. The poor performers overrated their performance, but did not rate it higher than the high performers did. It is more like the grandparent observed that everyone tends to think of themselves as close to average.
Databases aren't my field, but I would expect this to hurt performance by decreasing locality of keys.
This, of course, assumes that temporally-adjacent additions are related, but this seems like a common case for large data sets since they often arise from a series of measurements or transactions.
I created this account to make this reply because I imagine that someone here is expert enough to set me straight if I'm mistaken.
Postgres at least will store rows roughly in insert order. So whether you're using integers or UUIDs for primary keys won't affect on-disk layout.
When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.
class Bottom { private: Bottom(){} };