Hi Mirco,

> > Did you have any specific ideas in mind?
>
> Some ideas comes to my mind, but being not an expert in thread-
> programming I can say ingenuous things.

I am, nah, just kidding, I do use threads in my work, and they contain
many wonderful ways to shoot yourself in the foot.

> - move subqueries (those heavy ones) onto another thread

This could be done providing the two queries are independent (which
they usually aren't).

> - divide the job onto threads on a per-table basis

Could be done, but when you are joining the tables together, you are
either going to need to treat them as two independent queries and then
merge the results. It may be that it is more efficient to start with
one table, eliminate all but 5 records and join across from there.

> - let threads create useful temporary indexes on the fly

Can someone explain how a temporary index is beneficial? Creating an
index costs at least n. I suppose if you had a subquery that executed
for every record of the main query, and that did not have an index to
use, but it was effectively the same subquery for each main record,
there may be a benefit.

> - let the optimizer run on a separate thread

Until the optimiser has figured out the best plan of attack to solve
the query, what it the other thread supposed to do? Answer: Wait for
the optimiser to finish its job.

> - use threads to keep index selectivity updated

Can be done, although this is a fair bit of overhead.

---

Farming out processes to do in parralel is only beneficial if the work
can be done simultaneously. Otherwise, you just end up with the
overhead of managing threads with no performance gain.

One possible option I can see is with a union all statement, where the
different queries can run totally independently, but apart from that
it is going to be much more difficult.

I would rather work be done to improve SMP performance of Superserver
with multiple users (which is I believe the direction being taken).
This would let the garbage collection run without interfering too
badly with other users, and heavy reports not bring quick transactions
to their knees.

Adam