Here's some additional observations on this puzzling issue:

The slow table is "cmdb", the normal table is "cmdb2".  Both have the same number of rows according to "SELECT count(*)" (73553310).  However, sys.statistics shows something a bit different: 

sql>SELECT x.name, count(*) AS columns_with, z.count FROM sys.tables AS x, sys.columns AS y, sys.statistics AS z WHERE x.id = y.table_id AND y.id = z.column_id GROUP BY x.name, z.count;

+-------+--------------+----------+

| name  | columns_with | count    |

+=======+==============+==========+

| cmdb  |            8 | 73553310 |

| cmdb  |          145 | 73553311 |

| cmdb2 |          153 | 73553310 |

+-------+--------------+----------+

3 tuples

sql>

For the slow table, "cmdb", there are 145/153 columns that have an extra "row".  This row count mismatch causes it to skip parallelization optimizations in "monetdb5/optimizer/opt_mitosis.c", line 212.

A few related questions:

1) In the columnar model, is is valid for conceptual tuples to exist which don't have values for each column like this?  (This seems strange as now there's a difference between an explicit NULL and "not existing").  How might this situation have happened?  (Only transactional full-row inserts were applied to this DB).  Can this be repaired?

2) Is the conditional in "monetdb5/optimizer/opt_mitosis.c", line 212 sufficiently robust?  I may be misunderstanding the full context of this line, but it seems like we could still benefit from splitting/parallelization when r < rowcnt, no?

Thanks,

-Jeremy Norris