zerocrates
13 hours ago
Is it faster to convert a column like this to unsigned? Obviously assuming you don't use negative IDs in the application.
That's much more of a "kick the can down the road" solution to only double your usable range, but if all positive the values in the rows shouldn't actually have to change, just the column metadata, so it could theoretically be more or less instantaneous. I guess in practice this doesn't happen; the server would rather use its generic "rebuild the table" alter method for changing a column type.
But it seems like you could reasonably do it if it's a signed-to-unsigned change and there's no negative values and there's an index on the column to make checking that fact fast. Or one of those third-party/lower-level type tools could let you do it without any checking.
afandian
9 hours ago
I don't know what DB was used in this csae, but Postgres doesn't have unsigned integers. It always struck me as hugely wasteful, as e.g. sequences start at zero by default.
masklinn
8 hours ago
At $dayjob we've actually used this property once or twice: if you need to merge two tables you can keep the positive ids for the first one, and use negative ids for the second one. It only works once, but damn if it's not effective when you need it, and it conveniently flags all the records with an id under some limit (positive and negative both) as "pre-transition" record when you're looking for patterns.
afandian
4 hours ago
I’ve also seen positive and negative ids for entities with different properties (can’t recall what). Felt like an unnecessary hack though.
adamcharnock
12 hours ago
An interesting idea! I suspect a major speed up would come from the fact that the column is staying the same size. So (I assume) far fewer bytes would need to be moved around.