Duistere Pluizenbal on Nostr: I often struggle to disable the micro-optimization-addicted part of my brain when ...
I often struggle to disable the micro-optimization-addicted part of my brain when designing SQL schemas.
VNDB has a table with 4 enum columns, each supporting 5-6 possible values. Postgres encodes enums as 4 bytes, so those 4 columns occupy 16 bytes on disk. But the same information would comfortably fit in just 2 bytes!
Of course, I could merge the columns into a single smallint with some fancy bit twiddling, but that comes at the cost of awkward queries and complicating the codebase. The benefits aren't worth it either: space savings will likely be insignificant if you factor in other columns and row overhead, and it's unlikely to make much of a difference in terms of performance.
BUT STILL THAT INFORMATION COULD BE 8 TIMES SMALLER!
VNDB has a table with 4 enum columns, each supporting 5-6 possible values. Postgres encodes enums as 4 bytes, so those 4 columns occupy 16 bytes on disk. But the same information would comfortably fit in just 2 bytes!
Of course, I could merge the columns into a single smallint with some fancy bit twiddling, but that comes at the cost of awkward queries and complicating the codebase. The benefits aren't worth it either: space savings will likely be insignificant if you factor in other columns and row overhead, and it's unlikely to make much of a difference in terms of performance.
BUT STILL THAT INFORMATION COULD BE 8 TIMES SMALLER!