You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue results in a ~80 MB WAL database file for ~15,000 records. Tarring results in a 99% compression ratio so it's not bad for downlinking but bad for onboard disk usage. Consider that using the default journal mode results in ~630 KB database file for the same amount of data.
The current workaround is to not use WAL and revert to the default journal mode all while making the journal mode configurable via the application's config file: #130
We eventually want to use WAL because in the default mode a single write to the database locks the database for a short time, nothing, even reading, can access the database file at all. We need to use the WAL option so that reading and writing can proceed concurrently.
For the time being, it's OK to use the default journal mode instead of WAL because of the following mutex constraint: #132
The text was updated successfully, but these errors were encountered:
Some context with the following similar issue:
https://sqlite.org/forum/info/54e791a519a225de
This issue results in a ~80 MB WAL database file for ~15,000 records. Tarring results in a 99% compression ratio so it's not bad for downlinking but bad for onboard disk usage. Consider that using the default journal mode results in ~630 KB database file for the same amount of data.
The current workaround is to not use WAL and revert to the default journal mode all while making the journal mode configurable via the application's config file: #130
We eventually want to use WAL because in the default mode a single write to the database locks the database for a short time, nothing, even reading, can access the database file at all. We need to use the WAL option so that reading and writing can proceed concurrently.
For the time being, it's OK to use the default journal mode instead of WAL because of the following mutex constraint: #132
The text was updated successfully, but these errors were encountered: