> Trying to run separate parts of query execution in different threads we
> should sooner waste more time syncing between them. But there is one
> exception: we can separate fetching data to be sorted and sort itself
> with minimum syncs between threads. Certainly it makes sense only for
> really big sorts, when we do partial sort and merge results later. It's
> possible to start partial sorts in separate threads, as long as we have
> enough CPUs in the system. This should give an effect when restoring big
> databases. Certainly, in case when crazy user requested a huge amount of
> data to be returned in single query, parallel sort can be useful too.

I have the same idea sometime ago. I did some profiling of how index is
created. Short results :

3601037 calls of DPM_next costs 43.800 sec
3601036 calls of VIO_data costs 6.012 sec

3601036 calls of SORT_put costs 11.650 sec

First two rows (DPM_next and VIO_data) represented cost of fetch.

As you can see it is far more than calls to quicksort (called from SORT_put)
So - maximum gain we can reach if SORT_put will run in separate thread is
about 12 sec from 57 (43 + 6 + 8) sec, or about 21%. Sounds not bad, but:

a) whole process (call to IDX_create_index) costs 105.9 sec so overall gain
is lower

b) it is very hard to put all internals of SORT_put into separate thread and
it will need additional syncronisation which can be costly

c) if we put in separate thread, say, only calls to "put_run", we'll have much
less performance gain - in my test 2528 calls of "put_run" costs 2.360 sec


Regards,
Vlad