6 ms·
Haven’t many similar issues been solved in journaled file systems and/or things like database transaction logs and indexes? Real-time high precision accuracy is
by hsbauauvhabzb 2y ago
Haven’t many similar issues been solved in journaled file systems and/or things like database transaction logs and indexes? Real-time high precision accuracy is not required, knowing how big a directory is, is a frequent use case of directories. Hell, ‘df’ tracks this at the partition level, including edge cases, as does ‘du’
- Someone 2y agoAs far as I am aware, neither of those cascade sizes up. Also, doing that in databases isn’t a solved problem. count(*) can be slow in databases. See for example - PostgreSQL: https://dba.stackexchange.com/questions/314371/count-queries-are-too-slow-even-with-an-index-only-scan https://dba.stackexchange.com/questions/314371/count-queries..., https://wiki.postgresql.org/wiki/Count_estimate https://wiki.postgresql.org/wiki/Count_estimate - Oracle: https://forums.oracle.com/ords/apexds/post/select-count-very-slow-9199 https://forums.oracle.com/ords/apexds/post/select-count-very... (Both databases use MVCC (https://en.wikipedia.org/wiki/Multiversion_concurrency_control https://en.wikipedia.org/wiki/Multiversion_concurrency_contr...) to ensure that concurrent queries all see the database in a consistent state. That makes it necessary to visit each row and check their time stamp when counting rows)