4 ms·
Scaling code isn't always as simple as rewriting your search function to be faster. What if scaling to millions of objects forces real tradeoffs for the hundre
by dahfizz 3y ago
Scaling code isn't always as simple as rewriting your search function to be faster.
What if scaling to millions of objects forces real tradeoffs for the hundreds of objects case?
It feels like you're asking people to only create Postgres, but SQLite has a perfectly valid use case as well.
In this case, git checking the access time of 500k files is fundamentally slow. The only way around this is to change how git tracks files, which all come with other usability tradeoffs. Git itself supports a fsmonitor that makes handling more files faster, but very few people use it because the tradeoffs aren't worth it.
- adamckay 3y ago> It feels like you're asking people to only create Postgres, but SQLite has a perfectly valid use case as well. I don't mean this to be a "well actually" comment, but because I found it interesting when I learnt this a few weeks ago - some limits for SQLite [1] are actually higher than the limits for Postgres [2] (specifically the number of columns in a table and the maximum size of a single field). 1 - https://www.sqlite.org/limits.html https://www.sqlite.org/limits.html 2 - https://www.postgresql.org/docs/current/limits.html https://www.postgresql.org/docs/current/limits.html
- lordgrenville 3y agoI've been working with some SQLite databases that are >100GB lately, and wondering if this is a bad idea. The theoretical max size is 140TB, but there's a big gap between can and should.