| |
| ▲ | rv64imafdc 3 hours ago | parent | next [-] | | Hold 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 3 hours ago | parent [-] | | I 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. |
| |
| ▲ | tptacek 4 hours ago | parent | prev [-] | | Yeah, 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? |
|
