3 ms·
One big caveat to this sort of test. With DBs you are very often trading throughput for latency. Meaning, it's certainly possible to get "the absolute fastest
by cogman10 3y ago
One big caveat to this sort of test. With DBs you are very often trading throughput for latency.
Meaning, it's certainly possible to get "the absolute fastest inserts possible" but at the same time, you are impacting both other readers of that table AND writers across the db.
This also gets more messy when you are talking about multiple instances.
- voidstarcpp 3y agoWith SQLite by default nobody else can even read the database while it's being written, so your comment would be better directed to a conventional database server.
- argiopetech 3y agoNote that the default can be changed with a PRAGMA at compile time to Write-Ahead Logging (WAL) which is both faster and allows reading during writes. [0] https://www.sqlite.org/wal.html https://www.sqlite.org/wal.html
- voidstarcpp 3y agoIn my limited experiments WAL wasn't faster for high-row-speed writes. When rows/s are maximized SQLite is CPU limited by internal bytecode operations rather than waiting for disk stuff.
- argiopetech 3y agoToo late to edit: This should have said "at run time", as it's set by making a relatively normal (can't be inside a transaction) SQL query.
- RedShift1 3y agoIf you enable the WAL, reading while writing is possible. IMO it should be the default.