4 ms·

Some great things in this release: - official Jinja2 support, and a generic template interface - native postgres fields - uuid field and it is an LTS. Time

• crdoconnor 12y ago
  >uuid field This one is good. I kind of wish it were default for primary keys, since the number of times I got burned by having databases I couldn't easily merge (which UUIDs help a lot with) way exceeds the number of times I had performance/memory issues caused by actually using UUIDs.
  • kbaldor 12y ago
    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.
    • wulczer 12y ago
      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.
    • crdoconnor 12y ago
      It might negatively affect performance, yes. Performance shouldn't affect the decision to make it default, however. That would be premature optimization. The only good reason I can think of for not making it default would be backwards compatibility.