[Monetdb-developers] Key constraints and optimizers...
Dear developers....
I was checking the status of the SQL test web-site (cvs branch) and I found some red ones.
In the test src/test/BugConstraint/delete_primarykey_1643845.sql
If I run the normal Mtest the test is red (the err output).
The constraint error given is for the foreign key and not for the primary key (as in the stable output). If I ran with M4 the test is green the same happens if I set the optimizers off.
So we can conclude that the reason for this test being red are the optimizers and nothing else in SQL module.
I tried to give a look to see which optimizer is breaking the test, but no results. Tomorrow I will continue.
I also think that all the tests that are red (the ones related with primary keys) are due this problem.
Should I open a bug or this is enough? Because it is an existent test that is red ;)
Regards, Romulo
On Tue, Jul 31, 2007 at 02:25:04AM +0200, Romulo Goncalves wrote:
Dear developers....
I was checking the status of the SQL test web-site (cvs branch) and I
^^^^^^^^^^^^ guess you mean CVS development trunk (i.e., "Current"), right? (we use "branch" usually only for the "Stable" release branch ...)
found some red ones.
In the test src/test/BugConstraint/delete_primarykey_1643845.sql
If I run the normal Mtest the test is red (the err output).
The constraint error given is for the foreign key and not for the primary key (as in the stable output). If I ran with M4 the test is green the same happens if I set the optimizers off.
So we can conclude that the reason for this test being red are the optimizers and nothing else in SQL module.
Most failing SQL/5 tests are due to Martin's recent partition optimizer changes on Friday Jul 27 2007 --- just like the compilation problems in M5 ---; hence, yes it's M5 only, and related to / cause by optimizers. Guessing from Martin's checkin comments I think he's aware of these problems...
I tried to give a look to see which optimizer is breaking the test, but no results. Tomorrow I will continue.
I also think that all the tests that are red (the ones related with primary keys) are due this problem.
Should I open a bug or this is enough? Because it is an existent test that is red ;)
feel free.
Stefan
Regards, Romulo
Dear all,
Indeed, M5's partition manager BPM and its associated optimizer are being refined/debugged.
The partition handler is still in great flux. The target is to have the complete SQL test run with a BATs composed of a single partition. The next stage then is to break each BAT into two pieces as a prelude for adaptive partitioning.
Stefan Manegold wrote:
On Tue, Jul 31, 2007 at 02:25:04AM +0200, Romulo Goncalves wrote:
Dear developers....
I was checking the status of the SQL test web-site (cvs branch) and I
^^^^^^^^^^^^guess you mean CVS development trunk (i.e., "Current"), right? (we use "branch" usually only for the "Stable" release branch ...)
found some red ones.
In the test src/test/BugConstraint/delete_primarykey_1643845.sql
If I run the normal Mtest the test is red (the err output).
The constraint error given is for the foreign key and not for the primary key (as in the stable output). If I ran with M4 the test is green the same happens if I set the optimizers off.
So we can conclude that the reason for this test being red are the optimizers and nothing else in SQL module.
Most failing SQL/5 tests are due to Martin's recent partition optimizer changes on Friday Jul 27 2007 --- just like the compilation problems in M5 ---; hence, yes it's M5 only, and related to / cause by optimizers. Guessing from Martin's checkin comments I think he's aware of these problems...
I tried to give a look to see which optimizer is breaking the test, but no results. Tomorrow I will continue.
I also think that all the tests that are red (the ones related with primary keys) are due this problem.
Should I open a bug or this is enough? Because it is an existent test that is red ;)
feel free.
Stefan
Regards, Romulo
Stefan Manegold wrote:
On Tue, Jul 31, 2007 at 02:25:04AM +0200, Romulo Goncalves wrote:
Dear developers....
I was checking the status of the SQL test web-site (cvs branch) and I
^^^^^^^^^^^^guess you mean CVS development trunk (i.e., "Current"), right? (we use "branch" usually only for the "Stable" release branch ...)
Ups, you are right.
found some red ones.
In the test src/test/BugConstraint/delete_primarykey_1643845.sql
If I run the normal Mtest the test is red (the err output).
The constraint error given is for the foreign key and not for the primary key (as in the stable output). If I ran with M4 the test is green the same happens if I set the optimizers off.
So we can conclude that the reason for this test being red are the optimizers and nothing else in SQL module.
Most failing SQL/5 tests are due to Martin's recent partition optimizer changes on Friday Jul 27 2007 --- just like the compilation problems in M5 ---; hence, yes it's M5 only, and related to / cause by optimizers. Guessing from Martin's checkin comments I think he's aware of these problems...
I tried to give a look to see which optimizer is breaking the test, but no results. Tomorrow I will continue.
I also think that all the tests that are red (the ones related with primary keys) are due this problem.
Should I open a bug or this is enough? Because it is an existent test that is red ;)
Martin is aware of the problem, but in any case I will open the bug for better control.
Regards, Romulo
feel free.
Stefan
Regards, Romulo
Romulo Goncalves wrote:
Stefan Manegold wrote:
On Tue, Jul 31, 2007 at 02:25:04AM +0200, Romulo Goncalves wrote:
Dear developers....
I was checking the status of the SQL test web-site (cvs branch) and I
^^^^^^^^^^^^guess you mean CVS development trunk (i.e., "Current"), right? (we use "branch" usually only for the "Stable" release branch ...)
Ups, you are right.
found some red ones.
In the test src/test/BugConstraint/delete_primarykey_1643845.sql
If I run the normal Mtest the test is red (the err output).
The constraint error given is for the foreign key and not for the primary key (as in the stable output). If I ran with M4 the test is green the same happens if I set the optimizers off.
So we can conclude that the reason for this test being red are the optimizers and nothing else in SQL module.
Most failing SQL/5 tests are due to Martin's recent partition optimizer changes on Friday Jul 27 2007 --- just like the compilation problems in M5 ---; hence, yes it's M5 only, and related to / cause by optimizers. Guessing from Martin's checkin comments I think he's aware of these problems...
I tried to give a look to see which optimizer is breaking the test, but no results. Tomorrow I will continue.
I also think that all the tests that are red (the ones related with primary keys) are due this problem.
Should I open a bug or this is enough? Because it is an existent test that is red ;)
Martin is aware of the problem, but in any case I will open the bug for better control.
Before to do a mistake (as usual after vacations) should I open a bug for SQL (because the tests broken are from SQL module) or for M5 (because the code that breaks the tests is from M5) ?
I would bet in the first one, right?
Regards, Romulo
Regards, Romulo
feel free.
Stefan
Regards, Romulo
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
Romulo Goncalves wrote:
Romulo Goncalves wrote:
Stefan Manegold wrote:
On Tue, Jul 31, 2007 at 02:25:04AM +0200, Romulo Goncalves wrote:
Dear developers....
I was checking the status of the SQL test web-site (cvs branch) and I
^^^^^^^^^^^^guess you mean CVS development trunk (i.e., "Current"), right? (we use "branch" usually only for the "Stable" release branch ...)
Ups, you are right.
found some red ones.
In the test src/test/BugConstraint/delete_primarykey_1643845.sql
If I run the normal Mtest the test is red (the err output).
The constraint error given is for the foreign key and not for the primary key (as in the stable output). If I ran with M4 the test is green the same happens if I set the optimizers off.
So we can conclude that the reason for this test being red are the optimizers and nothing else in SQL module.
Most failing SQL/5 tests are due to Martin's recent partition optimizer changes on Friday Jul 27 2007 --- just like the compilation problems in M5 ---; hence, yes it's M5 only, and related to / cause by optimizers. Guessing from Martin's checkin comments I think he's aware of these problems...
I tried to give a look to see which optimizer is breaking the test, but no results. Tomorrow I will continue.
I also think that all the tests that are red (the ones related with primary keys) are due this problem.
Should I open a bug or this is enough? Because it is an existent test that is red ;)
Martin is aware of the problem, but in any case I will open the bug for better control.
Before to do a mistake (as usual after vacations) should I open a bug for SQL (because the tests broken are from SQL module) or for M5 (because the code that breaks the tests is from M5) ?
I would bet in the first one, right?
It doesn't really matter. If it incorrect it will be fixed (or should be anyway). If you think the bug is in SQL, report it as SQL bug. If you think it is in M5, report as M5 bug. And if you don't know, report it somewhere. Anywhere.
participants (4)
-
Martin Kersten -
Romulo Goncalves -
Sjoerd Mullender -
Stefan Manegold