HI guys, For one of my customers I'm getting the question how to reduce the disk usage.
I wrote the journalling and periodic backup of meta.db myself so I of course know how to disable these, what the consequences are and how to ensure that all still works and all that ;) My question to the team is to think with me on how we can further reduce disk space usage for products where this is a consideration (for example embedded appliances where additional storage is an expensive component if it has to be large). Next to disabling journaling and using synchronous mode in SQLite after putting meta.db in .local and adapting the Backup/Restore to operate on the main meta.db instead of the journal or periodic backup, I was thinking about disabling fts, but also disabling extracting and mining of nie:plainTextContent. But also a perhaps crazy idea would be to implement a virtual table for SQLite that can compress certain literals' columns. A kind of the opposite of a indexed property: it'll be very slow, but as it is rarely queried on it's fine that it is slow. Just that the property's value must still be stored for the times when it is needed. For example for properties like nie:plainTextContent, but then per resource would the cell be stored compressed or not (and all SQLite access to it would decompress it, for example collation would). The problem is that many users want nie:plainTextContent to be there, but they don't want it to consume so much diskspace (and it can be slow to access it). Another idea could be filesystem specific: pointing in SQLite, somehow, to the inode of the FS straight to the contents of the file whenever the file is a plain text one. This might be even more crazy. I don't know. Putting all of meta.db on a compressed filesystem is also an idea. Kind regards, Philip -- Philip Van Hoof Software developer Codeminded BVBA - http://codeminded.be _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
