You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20100101 Firefox/17.0
Build Identifier:
Looking into the details of bug #3163, the concurrent user test, I was looking into this sequence using valgrind and the debugger, to understand why each call seems to be associated with an MAL optimizer stack call in the concurrent user stress test.
Tracing it shows that each query is added to the cache separately.
This is not the intended behavior.
The template is the same and there is just 1 plan needed.
See 3163 for database schema and queries.
CREATE TABLE "big_data" (
A INT,
B INT,
C INT,
D VARCHAR(100),
E VARCHAR(128),
F VARCHAR(8000),
G DATE,
H DATE,
I DATE
);
SELECT A, D from big_Data where B=820795733 AND E ='UlWsbzcHZi5lyJjJF9AYFRiZPZxjHqFZai6spMitOilLXw01ETUGx6J1HdFIUiHJxDMVx81aZbfme5bgyW4q5K7SiKDTvU9cV';
SELECT A, D from big_Data where B=2032992976 AND E ='lfZl2Z4m6M3JrXVxwnLC7ILfys3DKYwwVaTesVWSwYkCAxhgHiAc';
SELECT A, D from big_Data where B=1911160577 AND E ='wMGcxuHT7NvpOfjgPAVNWDu0r0lHVJkO0xQ18jPWMa5jAqyt7s35AElW6iwzUiwryVELYwkxgxA';
SELECT A, D from big_Data where B=2000084679 AND E ='MYOXO3fvKn0Tn0AWrB9AVNkZxfJTK2lUbgOXWbdxnUJstQM4R4y51srknkJfRCDOwYt9SM6dFLzVwBu7VfAsriPQzpMmzoogyJ5rgmaJVNC4oBb3XPe';
sql>select * from querycache();
+-----------------------------------------------------------------------------------------------------------------------------------------------------------+-------+
| query
| count |
+===========================================================================================================================================================+=======+
| select * from querycache();
| 1 |
| select a, d from big_data where b=1911160577 and e ='wMGcxuHT7NvpOfjgPAVNWDu0r0lHVJkO0xQ18jPWMa5jAqyt7s35AElW6iwzUiwryVELYwkxgxA'; | 1 |
| select a, d from big_data where b=2032992976 and e ='lfZl2Z4m6M3JrXVxwnLC7ILfys3DKYwwVaTesVWSwYkCAxhgHiAc'; | 1 |
| select a, d from big_data where b=820795733 and e ='UlWsbzcHZi5lyJjJF9AYFRiZPZxjHqFZai6spMitOilLXw01ETUGx6J1HdFIUiHJxDMVx81aZbfme5bgyW4q5K7SiKDTvU9cV'; | 1 |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------+-------+
4 tuples (6.9s)
Reproducible: Always
Steps to Reproduce:
Load the database of bug #3163 and executed a few of its queries.
A single client interaction suffices.
Comment 18301
Date: 2012-12-21 23:06:57 +0100
From: @mlkersten
Changeset 206bbb53dad3 made by Martin Kersten mk@cwi.nl in the MonetDB repo, refers to this bug.
Date: 2012-12-21 22:59:40 +0100
From: @mlkersten
To: SQL devs <>
Version: 11.15.1 (Feb2013)
Last updated: 2013-01-22 09:29:15 +0100
Comment 18300
Date: 2012-12-21 22:59:40 +0100
From: @mlkersten
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20100101 Firefox/17.0
Build Identifier:
Looking into the details of bug #3163, the concurrent user test, I was looking into this sequence using valgrind and the debugger, to understand why each call seems to be associated with an MAL optimizer stack call in the concurrent user stress test.
Tracing it shows that each query is added to the cache separately.
This is not the intended behavior.
The template is the same and there is just 1 plan needed.
See 3163 for database schema and queries.
CREATE TABLE "big_data" (
A INT,
B INT,
C INT,
D VARCHAR(100),
E VARCHAR(128),
F VARCHAR(8000),
G DATE,
H DATE,
I DATE
);
SELECT A, D from big_Data where B=820795733 AND E ='UlWsbzcHZi5lyJjJF9AYFRiZPZxjHqFZai6spMitOilLXw01ETUGx6J1HdFIUiHJxDMVx81aZbfme5bgyW4q5K7SiKDTvU9cV';
SELECT A, D from big_Data where B=2032992976 AND E ='lfZl2Z4m6M3JrXVxwnLC7ILfys3DKYwwVaTesVWSwYkCAxhgHiAc';
SELECT A, D from big_Data where B=1911160577 AND E ='wMGcxuHT7NvpOfjgPAVNWDu0r0lHVJkO0xQ18jPWMa5jAqyt7s35AElW6iwzUiwryVELYwkxgxA';
SELECT A, D from big_Data where B=2000084679 AND E ='MYOXO3fvKn0Tn0AWrB9AVNkZxfJTK2lUbgOXWbdxnUJstQM4R4y51srknkJfRCDOwYt9SM6dFLzVwBu7VfAsriPQzpMmzoogyJ5rgmaJVNC4oBb3XPe';
sql>select * from querycache();
+-----------------------------------------------------------------------------------------------------------------------------------------------------------+-------+
| query
| count |
+===========================================================================================================================================================+=======+
| select * from querycache();
| 1 |
| select a, d from big_data where b=1911160577 and e ='wMGcxuHT7NvpOfjgPAVNWDu0r0lHVJkO0xQ18jPWMa5jAqyt7s35AElW6iwzUiwryVELYwkxgxA'; | 1 |
| select a, d from big_data where b=2032992976 and e ='lfZl2Z4m6M3JrXVxwnLC7ILfys3DKYwwVaTesVWSwYkCAxhgHiAc'; | 1 |
| select a, d from big_data where b=820795733 and e ='UlWsbzcHZi5lyJjJF9AYFRiZPZxjHqFZai6spMitOilLXw01ETUGx6J1HdFIUiHJxDMVx81aZbfme5bgyW4q5K7SiKDTvU9cV'; | 1 |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------+-------+
4 tuples (6.9s)
Reproducible: Always
Steps to Reproduce:
Load the database of bug #3163 and executed a few of its queries.
A single client interaction suffices.
Comment 18301
Date: 2012-12-21 23:06:57 +0100
From: @mlkersten
Changeset 206bbb53dad3 made by Martin Kersten mk@cwi.nl in the MonetDB repo, refers to this bug.
For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=206bbb53dad3
Changeset description:
Comment 18310
Date: 2012-12-27 22:14:04 +0100
From: @mlkersten
The bug seems resolved.
Comment 18376
Date: 2013-01-22 09:29:15 +0100
From: @sjoerdmullender
Oct2012-SP3 has been released.
The text was updated successfully, but these errors were encountered: