This is missing a couple big points from the previous discussion on the matter.
1.) Don’t use v4 unless you really need it to be random. Postgres has both uuid_generate_v1() and uuid_generate_v1mc() - the latter if you are concerned about the “security implications” of someone knowing your MAC - and the bonus to those is that they’re sortable. http://www.postgresql.org/docs/9.4/static/uuid-ossp.html
2.) The metrics provided are meaningless. The problem with using UUIDs as keys is that they’re just fancy strings under the hood, and JOIN performance completely tanks. You’re far better off using your INT of choice for machine-visible keys, and UUIDs for human-visible IDs.
This is missing a couple big points from the previous discussion on the matter.
1.) Don’t use v4 unless you really need it to be random. Postgres has both
uuid_generate_v1()anduuid_generate_v1mc()- the latter if you are concerned about the “security implications” of someone knowing your MAC - and the bonus to those is that they’re sortable. http://www.postgresql.org/docs/9.4/static/uuid-ossp.html2.) The metrics provided are meaningless. The problem with using UUIDs as keys is that they’re just fancy strings under the hood, and JOIN performance completely tanks. You’re far better off using your INT of choice for machine-visible keys, and UUIDs for human-visible IDs.
I have questions… is insert time really the only important metric? Won’t they take longer to compare on any query, as well?