3 ms·

> I'm saving 48 bytes per row you saving 24 bytes per row: downsizing 6 columns from 8 bytes to 4, which is fraction of your table size. If your system is sens

> I'm saving 48 bytes per row you saving 24 bytes per row: downsizing 6 columns from 8 bytes to 4, which is fraction of your table size. If your system is sensitive to such change, you likely should optimize something else. > Using bigint here would add absolutely nothing. I'm never going to have billions of users. I'm never going to have billions of different operating systems. I think you cherry picked some fictional examples which you won't combine in one table, and your real entities are different. It adds process safety: you don't need to play mind quizzes to estimate how system can grow/change in a N years.

arp242 2y ago
> cherry picked some fictional example What an incredibly rude and dismissive accusation. Here's my table: https://github.com/arp242/goatcounter/blob/master/db/schema.gotxt#L70 https://github.com/arp242/goatcounter/blob/master/db/schema.... – number of IDs is actually 7, not 6. I can give a lot more details and context on all of that and why it works the way it works and the savings are certainly not insignificant and theoretical, but save me real money in server costs every month. But I have little interest in talking to you further since you're just going to insult everyone who tries to inject the slightest nuance into "always use bigserial"-extremism. So good day to you.
- riku_iki 2y ago
  > https://github.com/arp242/goatcounter/blob/master/db/schema https://github.com/arp242/goatcounter/blob/master/db/schema.... - number of IDs is actually 7, not 6. the point is that some/many of those ids are not timezone and country, and potentially can grow high in cardinality.
  - arp242 2y ago
    No, my point is you accused me of lying at the drop of a hat for no good reason, and that this is demonstrably not true. Don't try and spinelessly slime your way out of that. And no, they I won't run out of IDs for them. "Potentially" anything can happen, but it won't happen here. After five year the furthest sequence is 0.86% on its way of being full.
    - riku_iki 2y ago
      > my point is you accused me of lying at the drop of a hat for no good reason I said you described fictional scenario, and it appears to be true, your table ID fields are very different than timezone, country and user_id.
      - deleted 2y ago
        [deleted]
- sgarland 2y ago
  I’d just like to congratulate you on perhaps the nicest “fuck off” I’ve ever read. Unrelated, I quite enjoyed reading your blog posts. Cheers!
sgarland 2y ago
> If your system is sensitive to such change, you likely should optimize something else. This isn’t even optimization, it’s just understanding your tools and needs. It’s akin to profiling your app under load, seeing that at worst it needs 1 GiB of RAM allocated, and then giving it 8 EiB just in case. By all means, if you can reasonably predict that a given table will near or pass 2^31 rows in the near future, just set it to BIGINT now. But as has been pointed out, most apps are never, ever going to have close to 2 billion users, or for that matter 2 billion anything. The only thing I can think of that might reasonably run up against that would be invoices for large scales, or object metadata for something like Notion.
- riku_iki 2y ago
  > But as has been pointed out, most apps are never, ever going to have close to 2 billion users, or for that matter 2 billion anything. T all computers will be fine with 640kb of ram

arp242 2y ago

> cherry picked some fictional example What an incredibly rude and dismissive accusation. Here's my table: https://github.com/arp242/goatcounter/blob/master/db/schema.gotxt#L70 https://github.com/arp242/goatcounter/blob/master/db/schema.... – number of IDs is actually 7, not 6. I can give a lot more details and context on all of that and why it works the way it works and the savings are certainly not insignificant and theoretical, but save me real money in server costs every month. But I have little interest in talking to you further since you're just going to insult everyone who tries to inject the slightest nuance into "always use bigserial"-extremism. So good day to you.

riku_iki 2y ago
> https://github.com/arp242/goatcounter/blob/master/db/schema https://github.com/arp242/goatcounter/blob/master/db/schema.... - number of IDs is actually 7, not 6. the point is that some/many of those ids are not timezone and country, and potentially can grow high in cardinality.
- arp242 2y ago
  No, my point is you accused me of lying at the drop of a hat for no good reason, and that this is demonstrably not true. Don't try and spinelessly slime your way out of that. And no, they I won't run out of IDs for them. "Potentially" anything can happen, but it won't happen here. After five year the furthest sequence is 0.86% on its way of being full.
  - riku_iki 2y ago
    > my point is you accused me of lying at the drop of a hat for no good reason I said you described fictional scenario, and it appears to be true, your table ID fields are very different than timezone, country and user_id.
    - deleted 2y ago
      [deleted]
sgarland 2y ago
I’d just like to congratulate you on perhaps the nicest “fuck off” I’ve ever read. Unrelated, I quite enjoyed reading your blog posts. Cheers!

sgarland 2y ago

> If your system is sensitive to such change, you likely should optimize something else. This isn’t even optimization, it’s just understanding your tools and needs. It’s akin to profiling your app under load, seeing that at worst it needs 1 GiB of RAM allocated, and then giving it 8 EiB just in case. By all means, if you can reasonably predict that a given table will near or pass 2^31 rows in the near future, just set it to BIGINT now. But as has been pointed out, most apps are never, ever going to have close to 2 billion users, or for that matter 2 billion anything. The only thing I can think of that might reasonably run up against that would be invoices for large scales, or object metadata for something like Notion.

riku_iki 2y ago
> But as has been pointed out, most apps are never, ever going to have close to 2 billion users, or for that matter 2 billion anything. T all computers will be fine with 640kb of ram