Your question is somewhat confusing but here I share some of our experience related to the same topic.

Our experiments with MonetFB shows that the default mitosis optimization MonetDB provides (splitting the longest column in the execution plan to initiate plan graph mitosis) works quite well on multicore systems for typical queries.

We did some further work on adding an optimization module where the table(s) selected for "mitosis"-splitting (and number of splits -- always being kept to be less, in total, than the number of available cores) can vary according to some "optimization strategy" related to our estimate of total processing cost.  In brief form, we published this work and some simplifications and findings last year.

Regards,
Masood Mortazavi 

On Sunday, January 4, 2015, Vijay Krishna <vijayakrishna55@gmail.com> wrote:
Hi,

I have been working on join performances with MonetDB. I tried using various optimizer pipelines. 

Few costly queries which took 15 seconds with the default pipeline, returned results as fast as 5 seconds with the 'no_mitosis_optimizer' pipeline. 

I am looking to study more on mitosis optimizer. Is there any reference on what does it do?
From the mserver5 man page, I got this - "forcefully activate mitosis even on small tables, i.e., split small tables in as many (tiny) pieces as there are cores (threads) available;" 
So, does this mean with the mitosis optimizer, the tables are split and processed? If so, then why are queries slower with mitosis optimizer in the pipeline? 

Also, from the monetdb man page, I was alerted that "Changing this setting is discouraged at all times."
What is the disadvantage of changing the optimizer pipeline to something other than the 'default_pipe'? Though the 'no_mitosis_optimizer' is stable, is it worth for production? 


Any help much appreciated. 



Thanks & Regards,

Vijayakrishna.P.
Mobile : (+91) 9500402305.