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
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.