2 ms·
> where SQLite had 179 issues revealed (vs. 11 in PostgreSQL) While I think the skepticism towards the 100% coverage effectiveness is valid, I'm not sure how t
by pizza234 6y ago
> where SQLite had 179 issues revealed (vs. 11 in PostgreSQL)
While I think the skepticism towards the 100% coverage effectiveness is valid, I'm not sure how to make meaningful conclusions from the number of bugs per product reported by that analysis (the analysis itself is certainly a really good job).
MySQL's bug tracker for example is huge (but I don't imply anything negative). During my last two work days, I've experienced two bugs, one of whom was new and caused a server crash with a SELECT. A couple of months ago I've found another server-crashing SELECT, which was also a new bug. I've filed a number of other bugs in the order of the dozens, over the last years.
There is a significant number of bugs reported in the SQLite fulltext functionality (if I understand "FTS" correctly). I don't see any in the MySQL section, and I'm perplexed, since the MySQL FT implementation is (relatively) poor, and I'd be surprised if an in-depth exam wouldn't find any bug.
Possibly, they've dedicated a significant amount of resources specifically to SQLite, either in terms of time spent testing or time spent tooling specific to it.
- mrigger 6y agoYes, you are right, the results are not comparable between DBMS that we tested. For MySQL, the large number of existing bugs prevented us from going further, and also testing more advanced functionality (like FTS). For SQLite (and DuckDB), bugs were typically fixed within hours, which is why we could comprehensively test them. For SQLite, we also tested three extensions (besides FTS, also R*Tree and DBSTAT).