Mirco,

Mirco Malaguti wrote:

>> 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 far from an expert threading programming too.

But as I saw, the problem relies on dependecies.

> Never mind, here they come:
> - move subqueries (those heavy ones) onto another thread
>

the main query needs the sub-query result to start processing (serialize
in the same way)

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

if there is no dependencies ok.

> - let threads create useful temporary indexes on the fly
>

not related to thread per se, but a two-edged sword. I don't like the
idea of magic things happening without my knowlodge, I would prefer
somekind of log to advise on hints to create useful indexes than the
server do it per itself.

> - let the optimizer run on a separate thread
>

a query needs the optimzer result prior to start running, so it's
serialized too

> - use threads to keep index selectivity updated
>

Here again, I don't like the idea of a thread trying to be smart and
using CPU resources to update something that could just be waste of
time, I prefer to schedule it myself to off peak hours.


What I think that paralel threads could bring some benefit is to break
some sentences in small parts and each thread solve that part and then
"merge" the result back, but I think its a great deal of job to make
this kind of optimization, and IMHO a small number of queries could be
splited this way.

I don't know what kind of paralelism could be done, tasks like one
thread scanning an index and other another (when multiple indexes could
be used on the same table) and those kind of things.

I think this is a really complex job to do.

> Mirco
>

I think that on normal operation a database server always serves more
than one query at a time, and this is sufficient to keep all processors
running it's threads to serve each of those queries even if each query
uses a single thread and does not run on parallel.

The kind of scenario where a SMP server are serving just one "user"
running a complex query that could bennefit from splitting this query
into smaller parts and running each part on a diferent CPU is very rare
IMHO.

But don't take my words, I am not a FB developer and neither a thread
programmer :-)

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br