2 ms·

No.

• jeffdavis 14y ago
  Why? Developers are relying more and more on database systems to solve their scalability needs. If you didn't have a database, you'd need to make sure to get the locking right even when doing completely different queries. A SQL database solves that problem by doing the concurrency control for you (possibly with locks, possibly not). That's what allows a developer to quickly and easily make a reasonably complex application that scales to many concurrent queries. (Sure, it sounds easy to add in a couple locks, or use STM. But then you need to make all of that work efficiently and also enforce unique constraints or something, and it starts to get a little more complex. Pretty soon you'll want secondary indexes, and a buffer pool, and checkpoints, etc.) Postgres even added in an efficient version of True Serializability[1], which eliminates SQL race conditions. So, can this all be extended to help with parallel execution of a single query? Yes. Some systems have had parallel query for a while, and cluster systems are also a different form of parallelism. [1] http://www.postgresql.org/docs/9.2/static/transaction-iso.html http://www.postgresql.org/docs/9.2/static/transaction-iso.ht...