> 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

It's a good idea to start kicking this around now, if only as an
exercise.
I'm sure you've already heard of research using GPUs for database
queries ( http://gamma.cs.unc.edu/DB/ ).
From the paper it may be surmised that the GPU would be used for
selecting the data, while the CPU groups and sums the results, hopefully
in parallel.

Rick DeBay

________________________________

From: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Alexandre
Benson Smith
Sent: Thursday, November 09, 2006 7:01 PM
To: Firebird-Architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Re: SMP - increasing single-query
performance?




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

Disclaimer: This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. RxStrategies, Inc. shall not be liable for the improper or incomplete transmission of the information contained in this communication or for any delay in its receipt or damage to your system. RxStrategies, Inc. does not guarantee that the integrity of this communication has been maintained nor that this communication is free from viruses, interceptions or interference.