How bloom filters made SQLite 10x faster
1–10 of 127 posts
Re: How bloom filters made SQLite 10x faster
#2Related:
SQLite: Past, Present, and Future - https://news.ycombinator.com/item?id=32675861 - Sept 2022 (143 comments)
Re: How bloom filters made SQLite 10x faster
#3[flagged]
Re: How bloom filters made SQLite 10x faster
#4[flagged]
Even if true, it seems like they're doing a pretty good job on their own.
Re: How bloom filters made SQLite 10x faster
#5SQLite is getting better and better. I am using it in production for a bunch of websites and never got a problem.
Re: How bloom filters made SQLite 10x faster
#6[flagged]
SQLite is self-described as not open contribution. So yes by their own measure they've made it more difficult to mainline features (and intentionally so).
Re: How bloom filters made SQLite 10x faster
#7SQLite is getting better and better. I am using it in production for a bunch of websites and never got a problem.
It should be fine for read-only data. If you want to write, be aware that only one process can write at a time, and if you forget to set busy_timeout at the start of the connection, it defaults to zero milliseconds and you'll get an error if another process has locked the database for writing while you try to read or write it. Client-server databases tend to handle concurrent writers better.
Re: How bloom filters made SQLite 10x faster
#8[flagged]
I submitted a bug report on SQLite a year or so back (a simple test case only, not a solution). The folks were super nice, and their patch went into the next release.
Re: How bloom filters made SQLite 10x faster
#9[flagged]
Open contribution isn’t a good in and of itself.
Re: How bloom filters made SQLite 10x faster
#10Just a thought, just because a general problem is NPHard doesn't mean that we can't find specific solutions quickly or that a given input is hard to search for. If the downstream effect results in an order of magnitude less work, it makes sense, it's just a tradeoff.