4 ms·
SQLite supports a single writer at a time, so writing large amounts of data limits your write throughput. A file system can cache data for several files concurr
by btrask 12y ago
SQLite supports a single writer at a time, so writing large amounts of data limits your write throughput. A file system can cache data for several files concurrently and fsync them independently when you're done.
I believe SQLite also has to write the data twice, using the WAL. Maybe there is an optimization to avoid that though.
- tines 12y ago> I believe SQLite also has to write the data twice, using the WAL. Maybe there is an optimization to avoid that though. If I understand correctly, it writes the data twice if you're not using WAL. With WAL, it only writes the data once [1]. [1]: The "Performance Considerations" section of https://www.sqlite.org/wal.html https://www.sqlite.org/wal.html
- Sami_Lehtinen 12y agoWith WAL mode data is always written twice for sure, unless same pages are updated several times inside the active part of WAL journal. Without WAL mode data isn't getting written twice unless you're updating it. These are annoyingly complex issues, and I'm not even 100% sure if I got it right, I'm just using common logic, I haven't checked source.
- seppo0010 12y agoThe data is written twice when using WAL. From the same link you pasted: > The original content is preserved in the database file and the changes are appended into a separate WAL file. The difference is whether the journal keeps the new data (WAL) or the old data (not WAL). If you are writing big chunks of data, WAL will probably be more I/O intensive. Taking a wild guess I'll say that if you are adding data to the database, and not using WAL, the data will only be written once since the journal won't keep a reference to old data if no pages is being overwritten.
- tines 12y agoAh, I see the difference now, thanks.