3 ms·
"one lightweight SELECT per millisecond" This reminds me of the teenager who told her dad that she was just a tiny little bit pregnant.
by felooboolooomba 6mo ago
"one lightweight SELECT per millisecond"
This reminds me of the teenager who told her dad that she was just a tiny little bit pregnant.
- giraffe_lady 6mo ago[flagged]
- tptacek 6mo agoYeah, again, to be clear: I get how SQLite works and I'm not dunking on the design, I'm just saying the comparison set up on this page snags. It's a classic LLM negated triptych, but "one of these things is not like the other": cache pressure: bad, writer contention: bad, kernel file watcher: ... good, actually? Intuitively seems better than this design?
- rv64imafdc 6mo agoHold on -- if it really is "one lightweight SELECT per millisecond", and you're saying a select is "a couple hundred microseconds", say generously 200us?, then you're spending 200us out of every 1000us just selecting. That's a lot of polling!
- giraffe_lady 6mo agoI mean only in the same sense that you spend 1 second per second doing something. Time is probably not the best way to evaluate the resources this consumes and I doubt it takes much of anything else either. It does seem weird though even for sqlite. I wonder how oban does it. I also wonder if OP knows oban can run on sqlite.
- sroussey 6mo agoThing of the battery! (read that in the way of "think of the children!")
- nine_k 6mo agoOne cannot be a little bit pregnant. But a DB can be only a little bit in the RAM, and specifically in the page cache. SQLite can act exactly like that, and it's damn fast as long as it does not need to durably write a transaction. Polling once a millisecond could spend a few microseconds. I wonder if using a tiny Redis instance, or even something like LevelDB would be even more efficient.
- Retr0id 6mo agoWith the file-watch APIs is that you don't need to poll at all - free is better than cheap.