4 ms·
Daytona from AT&T Labs built the database into the OS...I don’t think it worked very well. The inverted model makes more sense. A process per query isn't very s
by ablock 10y ago
Daytona from AT&T Labs built the database into the OS...I don’t think it worked very well. The inverted model makes more sense. A process per query isn't very scalable.
- sargun 10y agoGo on? Postgresql does process per session / query, and it scales ridiculously well, especially with the hilariously multi-core systems we have today. Although it doesn't handle unbounded concurrency, there are techniques (like manual locking, or pgbouncer) to deal with this.
- ablock 10y agoSo Daytona compiles and runs a new binary for each query, not just for each connection, and does all its coordination through files + pipes + shared memory. Query binaries even fork themselves for parallelism(!). My understanding is that the cost of switching between kernel and user space is pretty overwhelming. Maybe STM would help that someday but now you’ve implemented an actual database in the kernel... PostgreSQL’s process per user model makes way more sense but as you say still has upper limits on concurrency.
- eternalban 10y agoNot sure how to read that. Isn't simply 1 process per connection?
- sargun 10y agoYes. But you can't run more than one query per connection.
- eternalban 10y agoOne executing query per connection, meaning a connection maintains a serialized query processing model.