Date: 2017-11-16 10:34:03 +0100
From: @sjoerdmullender
To: SQL devs <>
Version: 11.27.9 (Jul2017-SP2)
CC: @njnes, @drstmane

Last updated: 2017-12-14 14:46:07 +0100

Comment 25887

Date: 2017-11-16 10:34:03 +0100
From: @sjoerdmullender

When you have a large table and do a simple select, mitosis kicks in and splits up the select in pieces, just to combine the (basically unaltered) pieces again before returning them.

Try this:

create table t (i) as (select * from sys.generate_series(cast(0 as integer), 10000000, 1));
explain select * from t limit 1000;
explain select * from t;

Both selects use mitosis.

This bug is derived from bug #6462.

Comment 25890

Date: 2017-11-16 12:54:56 +0100
From: @drstmane

Indeed, there is not much value in parallelizing query parts that do not (significantly) reduce the data volume (or do not have worse than linear complexity, or do not have significant CPU cost). We need to find a robust way to detect such situations easily and generically ...

Comment 25916

Date: 2017-11-26 18:35:43 +0100
From: @njnes

make sure a simple topn(project(basetable)) (or smaller) query isn't parallelised (as its only output production)

Comment 25918

Date: 2017-11-26 20:46:37 +0100
From: MonetDB Mercurial Repository <>

Changeset ffab2b52402d made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=ffab2b52402d

Changeset description:

fixes for bug #6470 (it seems to hint on new problems in the thetaselect though)