...
> As I have said before, multithreading queries within a connection
> process would be pretty cool, on a low load server, this could make a
> big performance increase, but it may be easier to create a couple I/O
> threads per connection process and devise some queuing mechanism for
> disk reads/write. In essence provide an asynchronous I/O system. This
> would give you the some of the performance of multithreading a query,
> while not requiring a complete thread-safe implementation.
The other use case would be a high load server with only one or a few
connections (big queries, few clients); see below.
> I think threading connections is a VERY bad idea. I am dubious that the
> amount of work will result in a decent return on investment.
Agreed. A subset area which *might* be a benefit for the use case above
is to allow threading of subqueries, which might happen after the
optimizer section of code. That is a (pretty big) fraction of the code,
not all of it, and it would still continue the benefits of the
process-per-client model while allowing a client to spread across
multiple processors.
The other area which could be exploited with restructuring to allow
post-optimizer threading is distributed databases, where each of those
subqueries could be rerouted to another server.
A first cut would be to allow read-only distributed databases; that
might demote the nomenclature for this to federated databases, but it is
still an interesting capability.
- Thomas
