Date: 2016-04-04 10:09:08 +0200
From: Vijay Krishna <>
To: GDK devs <>
Version: 11.21.17 (Jul2015-SP3)
CC: @njnes, vijayakrishna55

Last updated: 2016-06-23 10:24:01 +0200

Comment 22001

Date: 2016-04-04 10:09:08 +0200
From: Vijay Krishna <>

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
Build Identifier:

Data model : 10 tables - each with ~600 columns - all tables are EMPTY (No rows).

Query : One query that involves with 25 joins across all the 10 tables.
(Attached the create table statements and the actual query to simulate)

MonetDB version : July2015-SP3 (compiled from source code)

Environment :
Machine - CentOS VM
RAM - 128 GB
Free disk space - ~650 GB

The query is ran.

Expected result : return an empty set in a few seconds (or even minutes).
Actual result : the query rebooted this high end CentOS machine.
RAM - 128 GB utilised completely.
Swap memory - more than 600 GB was swapped from Hard disk before the system reboot.

After reboot, once I started the mserver again, the swap memory was freed.

Debugging :

1. Actually, the problem is not with executing the query - it was with generating the plan for the query. The same problem occurs while we try with "PLAN" or "EXPLAIN" the same query.
2. This happens with all the optimizers - even with minimal_pipe.

Issues :

1. Why should a query that runs on 10 EMPTY tables require memory in hundreds of GBs? (Remember all tables are empty tables).
2. Even if the Hard disk was full, why didn't the mserver throw an Out of Memory Exception without rebooting the machine?

Reproducible: Always

Steps to Reproduce:

1. Create the tables as in the create statements.
2. Execute the attached query.

Actual Results:

Machine reboots after eating up all the RAM and free hard disk space.

However, after reboot, if you start mserver again, the used hard disk space is freed.

Expected Results:

Should return a result in a few seconds.

Comment 22002

Date: 2016-04-04 10:10:23 +0200
From: Vijay Krishna <>

Created attachment 391
Sample Create table queries of the data model

Attached file: create.sql (application/octet-stream, 119221 bytes)
Description: Sample Create table queries of the data model

Comment 22003

Date: 2016-04-04 10:11:23 +0200
From: Vijay Krishna <>

Created attachment 392
The problematic query that eats up disk space and ultimately crashing the server

Attached file: crashQuery.sql (application/octet-stream, 3293 bytes)
Description: The problematic query that eats up disk space and ultimately crashing the server

Comment 22044

Date: 2016-04-14 18:33:21 +0200
From: MonetDB Mercurial Repository <>

Changeset a0f99c9ccbe6 made by Jennie Zhang y.zhang@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=a0f99c9ccbe6

Changeset description:

Added test for bug #3972

Comment 22054

Date: 2016-04-16 15:38:29 +0200
From: MonetDB Mercurial Repository <>

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

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=2737d13aca59

Changeset description:

fixes for bug #3972,
	no longer wrap outerjoins with projects.
	don't add extra internal columns (recursively)
	improve optimizer for this case

Comment 22055

Date: 2016-04-16 15:42:12 +0200
From: @njnes

the outerjoin query introduced many projections which the relational optimizer didn't handle well. The optimizer is improved and way less projection columns are generated. The query now runs fine.