February 2013 - users-list

[MonetDB-users] Proofreading your professional documents
by Richard Hounslow 24 Feb '24

24 Feb '24

Dear Professor/Lecturer Please excuse us for contacting you directly. We are offering an efficient service to help you ensure your academic and professional work is written in perfect English. We will check the grammar and style of your work and return it to you to meet your requirements and deadlines. Proof-Reading-Service.com can provide you with a professional proofreading service at a very reasonable rate. All our proofreaders are highly qualified native English speakers. Many work as leading academics in their fields and all have extensive experience of proofreading to the highest standards. If you are interested in our service, please take a look at our website: www.proof-reading-service.com All you have to do is send us your document as a word attachment with the deadline and we will guarantee delivery of a perfectly written document to give you complete confidence when you submit your work. The fee is worked out on a flat rate (£6.95 per thousand words or 0.695 pence per word), so you know exactly how much the proofreading will cost in advance. Once we have received your document(s) we will confirm the word count, the price and the deadline. If you have not heard from us within 2 hours during normal business hours after you have sent your work please resend it from a different email account or send the file to proofreadings(a)gmail.com. We look forward to hearing from you! Yours faithfully Proof-Reading-Service.com

2 2

good new monetdb question on stackoverflow
by Anthony Damico 28 Feb '13

28 Feb '13

http://stackoverflow.com/questions/15136868/why-is-group-by-giving-only-one… I couldn't figure out the answer..

2 1

Investigating Segfault
by Percy Wegmann 25 Feb '13

25 Feb '13

Dear Monet Team, We're having an issue in which certain data is causing mserver5 to crash. After this condition is hit, mserver5 crashes at every startup and always dumps an identical core. We're running Monet 11.13.7 on Ubuntu Linux 64 bit. The error is happening on line 1142 of gdk_atoms.c: if (GDK_STRCMP(v, (str) (next + 1) + extralen) == 0) { Examining the core dump revealed that (next + 1) + extralen is referring to an out of bounds address. Here's the backtrace: #0 0x00007faf58414829 in strPut (h=0x1e2d180, dst=0x7fff592cf8f8, v=0x314dac0 "SAD014H1") at gdk_atoms.c:1142 #1 0x00007faf582dc935 in BATappend (b=0x1e2cf90, n=0x32dfdb0, force=1 '\001') at gdk_batop.c:578 #2 0x00007faf584c301e in la_bat_updates (lg=0x2d9b030, la=0x2c3ef48) at gdk_logger.c:429 #3 0x00007faf584c3cf9 in la_apply (lg=0x2d9b030, c=0x2c3ef48) at gdk_logger.c:645 #4 0x00007faf584c3f26 in tr_commit (lg=0x2d9b030, tr=0x2e247d0) at gdk_logger.c:705 #5 0x00007faf584c4533 in logger_readlog (lg=0x2d9b030, filename=0x7fff592d1e80 "/opt/clicksecurity/data/_monetdb/click/sql_logs/sql/log.56") at gdk_logger.c:823 #6 0x00007faf584c482a in logger_readlogs (lg=0x2d9b030, fp=0x2d9b160, filename=0x7fff592d3f90 "/opt/clicksecurity/data/_monetdb/click/sql_logs/sql/log") at gdk_logger.c:896 #7 0x00007faf584c6f3e in logger_new (debug=0, fn=0x7faf500adfa8 "sql", logdir=0x7faf50090a08 "sql_logs", dbname=0x1fa3da0 "click", version=52001, prefuncp=0x7faf500746a1 <bl_preversion>, postfuncp=0x7faf500747ed <bl_postversion>) at gdk_logger.c:1420 #8 0x00007faf584c704e in logger_create (debug=0, fn=0x7faf500adfa8 "sql", logdir=0x7faf50090a08 "sql_logs", dbname=0x1fa3da0 "click", version=52001, prefuncp=0x7faf500746a1 <bl_preversion>, postfuncp=0x7faf500747ed <bl_postversion>) at gdk_logger.c:1446 #9 0x00007faf50075b19 in bl_create (logdir=0x7faf50090a08 "sql_logs", dbname=0x1fa3da0 "click", cat_version=52001) at bat_logger.c:249 #10 0x00007faf50060ce4 in store_init (debug=0, store=store_bat, logdir=0x7faf50090a08 "sql_logs", dbname=0x1fa3da0 "click", stk=0) at store.c:1287 #11 0x00007faf4ffe3d3c in mvc_init (dbname=0x1fa3da0 "click", debug=0, store=store_bat, stk=0) at sql_mvc.c:51 #12 0x00007faf4ff66874 in SQLinit () at sql_scenario.c:230 #13 0x00007faf4ff6651f in SQLprelude () at sql_scenario.c:159 #14 0x00007faf58b3085d in malCommandCall (stk=0x2d36e80, pci=0x2ea5520) at mal_interpreter.c:137 #15 0x00007faf58b331b5 in runMALsequence (cntxt=0x7faf5988c020, mb=0x1e04310, startpc=1, stoppc=0, stk=0x2d36e80, env=0x0, pcicaller=0x0) at mal_interpreter.c:710 #16 0x00007faf58b323c1 in runMAL (cntxt=0x7faf5988c020, mb=0x1e04310, startpc=1, mbcaller=0x0, env=0x0, pcicaller=0x0) at mal_interpreter.c:454 #17 0x00007faf58b60a08 in MALengine (c=0x7faf5988c020) at mal_session.c:619 #18 0x00007faf58b5f21f in malBootstrap () at mal_session.c:64 #19 0x00007faf58b1313b in mal_init () at mal.c:244 #20 0x000000000040340e in main (argc=22, av=0x7fff592db568) at mserver5.c:582 I'm digging into it now, but I was hoping that it might ring some bells. Thanks, -- Percy Wegmann +1 512 637 8500 ext 148

2 3

MonetDB Feb2013 Release --dbpath option
by Gennadiy 22 Feb '13

22 Feb '13

Hello, Before MonetDB Feb2013 Release, I used to start MonetDB using the following Windows command: MSQLserver.bat --dbname=MyNewDatabase MSQLserver.bat called M5server.bat, M5server.bat set --dbfarm option. The result was that database with name specified with --dbname option was created in the directory specified with --dbfarm option. MonetDB Feb2013 Release replaced --dbname and --dbfarm options with single --dbpath option. This --dbpath option is set to some_path\dbfarm\demo in M5server.bat. So, now (MonetDB Feb2013 Release) when I start MonetDB with the following Windows command: MSQLserver.bat --dbpath=some_path\MyNewDatabase MonetDB ignores my --dbpath option, because it uses --dbpath option from M5server.bat! So, how can I start MonetDB and create my own database? Thank you very much, Gennadiy

1 1

Windows Concurrency Error when accessing two separate tables in two separate mclient instances connected to the same mserver?
by Anthony Damico 22 Feb '13

22 Feb '13

Hi, I am using a brand new mserver.exe instance of MonetDB5 on Windows. I am getting the error: "COMMIT: transaction is aborted because of concurency conflicts, will ROLLBACK instead" that I'm not sure I should? Shouldn't I be able to use the COPY command on two separate CSV files into two separate data tables at once? I don't think this behavior is correct, but maybe I'm wrong? :/ If this is incorrect behavior, should I file a bug report for this? The files you can use to re-create this error are: http://downloads.cms.gov/BSAPUF/2008_BSA_PartD_Events_PUF_1.zip http://downloads.cms.gov/BSAPUF/2008_BSA_PartD_Events_PUF_2.zip I create an mserver.exe instance with: # MonetDB 5 server v11.13.9 "Oct2012-SP3" # Serving database 'bsapuf', using 8 threads # Compiled for x86_64-pc-winnt/64bit with 64bit OIDs dynamically linked # Found 7.860 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2013 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information # Listening for connection requests on mapi:monetdb://127.0.0.1:50003/ # MonetDB/JAQL module loaded # MonetDB/SQL module loaded Then I ran this command in the first mclient: CREATE TABLE bsa1 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE PRECISION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION, PDE_DRUG_STR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION, PDE_DRUG_DOSE_CD DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION, PDE_DRUG_QTY_DIS DOUBLE PRECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION, PDE_DRUG_COST DOUBLE PRECISION, PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION, PDE_DRUG_TYPE_CD DOUBLE PRECISION) ; copy 1000000 offset 2 records into bsa1 from 'c:\\temp\\2008_BSA_PartD_Events_PUF_1.csv' using delimiters ',' NULL AS '' ; And (at the same time) ran this command in the second mclient: CREATE TABLE bsa2 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE PRECISION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION, PDE_DRUG_STR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION, PDE_DRUG_DOSE_CD DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION, PDE_DRUG_QTY_DIS DOUBLE PRECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION, PDE_DRUG_COST DOUBLE PRECISION, PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION, PDE_DRUG_TYPE_CD DOUBLE PRECISION) ; copy 1000000 offset 2 records into bsa2 from 'c:\\temp\\2008_BSA_PartD_Events_PUF_2.csv' using delimiters ',' NULL AS '' ; Here were the results. One worked, one didn't: Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\anthonyd.KFF>cd .. C:\Users>cd .. C:\>cd "Program Files\MonetDB\MonetDB5" C:\Program Files\MonetDB\MonetDB5>mclient -p 50003 "bsapuf" user(win32):monetdb password: Welcome to mclient, the MonetDB/SQL interactive terminal (Oct2012-SP3) Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsapuf' Type \q to quit, \? for a list of available commands auto commit mode: on sql> sql> sql>CREATE TABLE bsa2 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE PRECI SION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION, PDE_DRUG_S TR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION, PDE_DRUG_DOSE_CD DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION, PDE_DRUG_QTY_DIS DOUBLE P RECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION, PDE_DRUG_COST DOUBLE PRECISION, PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION, PDE_DRUG_TYPE_CD DOUBLE PRECISION) ; operation successful (9.511ms) sql> sql>copy 1000000 offset 2 records into bsa2 from 'c:\\temp\\2008_BSA_PartD_Event s_PUF_2.csv' using delimiters ',' NULL AS '' ; 1000000 affected rows (42.4s) sql> XXXXXXXXXXXXXXXXXXXXXXXXXXXXX Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\anthonyd.KFF>cd .. C:\Users>cd .. C:\>cd "Program Files\MonetDB\MonetDB5" C:\Program Files\MonetDB\MonetDB5>mclient -p 50003 "bsapuf" user(win32):monetdb password: Welcome to mclient, the MonetDB/SQL interactive terminal (Oct2012-SP3) Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsapuf' Type \q to quit, \? for a list of available commands auto commit mode: on sql>\d sql>CREATE TABLE bsa1 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE PRECI SION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION, PDE_DRUG_S TR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION, PDE_DRUG_DOSE_CD DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION, PDE_DRUG_QTY_DIS DOUBLE P RECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION, PDE_DRUG_COST DOUBLE PRECISION, PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION, PDE_DRUG_TYPE_CD DOUBLE PRECISION) ; operation successful (8.636ms) sql> sql>copy 1000000 offset 2 records into bsa1 from 'c:\\temp\\2008_BSA_PartD_Event s_PUF_1.csv' using delimiters ',' NULL AS '' ; 1000000 affected rows (41.6s) COMMIT: transaction is aborted because of concurency conflicts, will ROLLBACK in stead sql> sql> Thanks as always! Anthony

2 2

Announcement: New Feb2013 Feature release of MonetDB suite
by Sjoerd Mullender 22 Feb '13

22 Feb '13

The MonetDB team at CWI/MonetDB BV is pleased to announce the Feb2013 feature release of the MonetDB suite of programs. More information about MonetDB can be found on our website at <http://www.monetdb.org/>. For details on this release, please see the release notes at <http://www.monetdb.org/Downloads/ReleaseNotes>. As usual, the download location is <http://dev.monetdb.org/downloads/>. Feb 2013 feature release Testing Environment * enabled "top-level" Mtest.py So far, while Mtest.py could be called in any subdirectory of the MonetDB source tree (and could then run all tests in the entire sub-tree), it was not possible to call Mtest.py in the top-level MonetDB source directory to run all tests. Instead, to run all tests, Mtest.py had to be called at least 4 times, once in each of these directories: "clients", "monetdb5", "sql", "geom". Now, it is possible to call Mtest.py once in the top-level MonetDB source directory to run all tests in one go. The behaviour of calling Mtest.py in any subdirectory, including the four mentioned above, did not changed, other than that now obsolete command line options "-p / --package <package>" and "-5 / --monetdb5" have been removed. Java Module * merocontrol was changed to return server URIs, and lastStop time. Connections and dbpath were removed. * Mapi protocol v8 support was removed from MapiSocket. Protocol v8 has not been used by the servers any more since Apr2012 release Client Package * Mapi protocol v8 support was removed from all client drivers. Protocol v8 has not been used by the servers any more since Apr2012 release * The tool mnc was removed from installations * msqldump: Implmented an option (--table/-t) to dump a single table. * Changed msqdump's trace option to be in line with mclient. In both cases, the long option is --Xdebug and the short option is -X. MonetDB5 Server * mserver5: The --dbname and --dbfarm options have been replaced by the single --dbpath option. * The scheduler of mserver5 was changed to use a fixed set of workers to perform the work for all connected clients. Previously, each client connection had its own set of workers, easily causing resource problems upon multiple connections to the server. Merovingian * Upgrade support for dbfarms from Mar2011 and Aug2011 was dropped * monetdb status now uses a more condensed output, to cater for the uris being shown, and prints how long a database is stopped, or how long ago it crashed * monetdb status now prints the connection uri for each database, when available. The connections and database path properties have been dropped. * monetdb status now prints last crash date only if the database has not been started since. Bug Fixes * 2291: small doubles end up as NULL after arithmetic * 3215: Calculation Date function using interval and year * 3033: stethoscope needs better documentation * 3084: Timestamp arithmetic very slow (especially on Windows) * 3125: Python tests fail after recent Python API changes * 3172: assertion fails on table function with subselects as parameters * 3178: one scan is enough to implement ALGstdev_@1 in monetdb5/modules/kernel/algebra.mx * 3179: LIKE: batstr.like+algebra.uselect called instead of pcre.like_filter * 3193: Expressions not supported in the GROUP BY or ORDER BY clause. * 3216: "unknown property" error setting format and width in .monetdb file * 3217: gdk_posix fails to compile under NetBSD * 3221: can no execute large statements * 3227: MT_set_lock() call on an non-initialized lock

5 11

MonetDB documentation
by Brandon Jackson 15 Feb '13

15 Feb '13

Just curious, I follow the mailing lists closely very recently. Is there a way, or does it make sense for someone like me to have access to update the MonetDb documentation based on responses from the maintainers here? I would be happy to collect some of this information and send it in for review before posting as documentation. Brandon Sent from my iPhone

2 2

Windows Networked Drive Issue with COPY INTO
by Anthony Damico 15 Feb '13

15 Feb '13

I am running MonetDB5 Oct 2012 SP3 on my work Windows 7 desktop computer. My office has what I imagine is a pretty typical mix of networked machines, with a few more powerful servers and larger shared drives that everyone can connect to. (1) When I attempt to import a large CSV file into a MonetDB server on the _local_ disk (C:\My Directory\MonetDB\dbfarm), the importation command runs as expected. (2) When I attempt to import the same CSV file to a MonetDB server stored on a networked drive, the import command fails. (3) Finally, when I *remote desktop* into the server that the networked drive is actually attached to, the importation succeeds again! Here's the error seen in scenario (2) -- GDKerror:!ERROR: GDKunlink(bat\13\1327.tail) !OS: The process cannot access the file because it is being used by another process. GDKunlink(bat\13\1327.theap) !OS: The process cannot access the file because it is being used by another process. So it seems pretty clear that something about windows networked drives is the culprit. This error does not occur on every file (larger files seem more prone to the error), but if an import command does not work on a file, it _consistently_ does not work on that file. As an example, importing this large file works with methods (1) and (3) but not (2) -- http://downloads.cms.gov/BSAPUF/2008_BSA_Carrier_Line_Items_PUF_1.zip I tried disabling the windows firewall and using different server ports, but I still hit the above error. I spoke with Hannes about it briefly, he said: "The issue is probably related to the Windows mmap() implementation when talking to a SMB filesystem. It is far from certain that there is something we can do about this, but in either case, we'd like to know about it." Should I submit an official bug report to http://bugs.monetdb.org/ ? Perhaps we are overlooking something obvious about our windows network's configuration.. Thanks!!! Here is my MonetDB server info, followed by the COPY INTO commands run in -X mode for each of the three scenarios: # MonetDB 5 server v11.13.9 "Oct2012-SP3" # Serving database 'bsa', using 2 threads # Compiled for x86_64-pc-winnt/64bit with 64bit OIDs dynamically linked # Found 15.873 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2013 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information # Listening for connection requests on mapi:monetdb://127.0.0.1:50001/ # MonetDB/JAQL module loaded # MonetDB/SQL module loaded ************************** (1) - local disk - works ----- fetch next block: start at:196 got next block: length:0 text: got complete block: text:☺ read_line:☺ Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsa' closing result set Type \q to quit, \? for a list of available commands auto commit mode: on mapi_query:46:SET TIME ZONE INTERVAL '-05:00' HOUR TO MINUTE fetch next block: start at:198 got next block: length:3 text:&3 got complete block: text:&3 read_line:&3 allocating new result set fetch next block: start at:201 got next block: length:0 text: got complete block: text:☺ read_line:☺ closing result set sql>create table mytable ( mapi_query_part:23:create table mytable ( fetch next block: start at:203 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:206 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_id VARCHAR(255), mapi_query_part:27: car_line_id VARCHAR(255), fetch next block: start at:208 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:211 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> bene_sex_ident_cd INTEGER, mapi_query_part:28: bene_sex_ident_cd INTEGER, fetch next block: start at:213 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:216 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> bene_age_cat_cd INTEGER, mapi_query_part:26: bene_age_cat_cd INTEGER, fetch next block: start at:218 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:221 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_icd9_dgns_cd VARCHAR(255), mapi_query_part:37: car_line_icd9_dgns_cd VARCHAR(255), fetch next block: start at:223 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:226 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_hcpcs_cd VARCHAR(255), mapi_query_part:33: car_line_hcpcs_cd VARCHAR(255), fetch next block: start at:228 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:231 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_betos_cd VARCHAR(255), mapi_query_part:33: car_line_betos_cd VARCHAR(255), fetch next block: start at:233 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:236 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_srvc_cnt INTEGER, mapi_query_part:28: car_line_srvc_cnt INTEGER, fetch next block: start at:238 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:241 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_prvdr_type_cd INTEGER, mapi_query_part:33: car_line_prvdr_type_cd INTEGER, fetch next block: start at:243 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:246 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_cms_type_srvc_cd VARCHAR(255), mapi_query_part:41: car_line_cms_type_srvc_cd VARCHAR(255), fetch next block: start at:248 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:251 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_place_of_srvc_cd INTEGER, mapi_query_part:36: car_line_place_of_srvc_cd INTEGER, fetch next block: start at:253 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:256 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_hcpcs_pmt_amt INTEGER mapi_query_part:27: car_hcpcs_pmt_amt INTEGER fetch next block: start at:258 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:261 got next block: length:0 text: got complete block: text:☺ read_line:☺ more>) ; mapi_query_part:4:) ; fetch next block: start at:263 got next block: length:3 text:&3 got complete block: text:&3 read_line:&3 allocating new result set fetch next block: start at:266 got next block: length:0 text: got complete block: text:☺ read_line:☺ operation successful (118.294ms) closing result set sql> fetch next block: start at:268 got next block: length:0 text: got complete block: text:☺ read_line:☺ sql>COPY 9676440 offset 2 records INTO mytable FROM 'C:\My Directory\BSAPUF\2008 \2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL AS ' ' ; mapi_query_part:160:COPY 9676440 offset 2 records INTO mytable FROM 'C:\My Direc tory\BSAPUF\2008\2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n ','\"' NULL AS '' ; fetch next block: start at:270 got next block: length:14 text:&2 9676439 -1 got complete block: text:&2 9676439 -1 read_line:&2 9676439 -1 allocating new result set fetch next block: start at:284 got next block: length:0 text: got complete block: text:☺ read_line:☺ 9676439 affected rows (3m 26s) closing result set sql> ************************** (2) - networked disk - fails ----- read_line:☺ more> car_line_id VARCHAR(255), mapi_query_part:27: car_line_id VARCHAR(255), fetch next block: start at:208 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:211 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> bene_sex_ident_cd INTEGER, mapi_query_part:28: bene_sex_ident_cd INTEGER, fetch next block: start at:213 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:216 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> bene_age_cat_cd INTEGER, mapi_query_part:26: bene_age_cat_cd INTEGER, fetch next block: start at:218 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:221 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_icd9_dgns_cd VARCHAR(255), mapi_query_part:37: car_line_icd9_dgns_cd VARCHAR(255), fetch next block: start at:223 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:226 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_hcpcs_cd VARCHAR(255), mapi_query_part:33: car_line_hcpcs_cd VARCHAR(255), fetch next block: start at:228 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:231 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_betos_cd VARCHAR(255), mapi_query_part:33: car_line_betos_cd VARCHAR(255), fetch next block: start at:233 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:236 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_srvc_cnt INTEGER, mapi_query_part:28: car_line_srvc_cnt INTEGER, fetch next block: start at:238 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:241 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_prvdr_type_cd INTEGER, mapi_query_part:33: car_line_prvdr_type_cd INTEGER, fetch next block: start at:243 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:246 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_cms_type_srvc_cd VARCHAR(255), mapi_query_part:41: car_line_cms_type_srvc_cd VARCHAR(255), fetch next block: start at:248 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:251 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_place_of_srvc_cd INTEGER, mapi_query_part:36: car_line_place_of_srvc_cd INTEGER, fetch next block: start at:253 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:256 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_hcpcs_pmt_amt INTEGER mapi_query_part:27: car_hcpcs_pmt_amt INTEGER fetch next block: start at:258 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:261 got next block: length:0 text: got complete block: text:☺ read_line:☺ more>) ; mapi_query_part:4:) ; fetch next block: start at:263 got next block: length:3 text:&3 got complete block: text:&3 read_line:&3 allocating new result set fetch next block: start at:266 got next block: length:0 text: got complete block: text:☺ read_line:☺ operation successful (289.145ms) closing result set sql> fetch next block: start at:268 got next block: length:0 text: got complete block: text:☺ read_line:☺ sql>COPY 9676440 offset 2 records INTO mytable FROM 'C:\My Directory\BSAPUF\2008 \2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL AS ' ' ; mapi_query_part:160:COPY 9676440 offset 2 records INTO mytable FROM 'C:\My Direc tory\BSAPUF\2008\2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n ','\"' NULL AS '' ; fetch next block: start at:270 got next block: length:252 text:!GDKerror:!ERROR: GDKunlink(bat\13\1327.tail) !!OS: The process cannot access the file because it is being used by another pro cess. !GDKunlink(bat\13\1327.theap) !!OS: The process cannot access the file because it is being used by another pro cess. ! got complete block: text:!GDKerror:!ERROR: GDKunlink(bat\13\1327.tail) !!OS: The process cannot access the file because it is being used by another pro cess. !GDKunlink(bat\13\1327.theap) !!OS: The process cannot access the file because it is being used by another pro cess. ! read_line:!GDKerror:!ERROR: GDKunlink(bat\13\1327.tail) allocating new result set got complete block: text:!!OS: The process cannot access the file because it is being used by anothe r process. !GDKunlink(bat\13\1327.theap) !!OS: The process cannot access the file because it is being used by another pro cess. ! read_line:!!OS: The process cannot access the file because it is being used by a nother process. got complete block: text:!GDKunlink(bat\13\1327.theap) !!OS: The process cannot access the file because it is being used by another pro cess. ! read_line:!GDKunlink(bat\13\1327.theap) got complete block: text:!!OS: The process cannot access the file because it is being used by anothe r process. ! read_line:!!OS: The process cannot access the file because it is being used by a nother process. got complete block: text:! read_line:! fetch next block: start at:522 got next block: length:0 text: got complete block: text:☺ read_line:☺ GDKerror:!ERROR: GDKunlink(bat\13\1327.tail) !OS: The process cannot access the file because it is being used by another proc ess. GDKunlink(bat\13\1327.theap) !OS: The process cannot access the file because it is being used by another proc ess. closing result set sql> ************************** (3) - remote desktop into server so networked disk becomes local disk - works ----- read_line:[ "monet_release", "Oct2012-SP3" ] fetch next block: start at:196 got next block: length:0 text: got complete block: text:☺ read_line:☺ Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsa' closing result set Type \q to quit, \? for a list of available commands auto commit mode: on mapi_query:46:SET TIME ZONE INTERVAL '-05:00' HOUR TO MINUTE fetch next block: start at:198 got next block: length:3 text:&3 got complete block: text:&3 read_line:&3 allocating new result set fetch next block: start at:201 got next block: length:0 text: got complete block: text:☺ read_line:☺ closing result set sql>create table mytable3 ( mapi_query_part:24:create table mytable3 ( fetch next block: start at:203 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:206 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_id VARCHAR(255), mapi_query_part:27: car_line_id VARCHAR(255), fetch next block: start at:208 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:211 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> bene_sex_ident_cd INTEGER, mapi_query_part:28: bene_sex_ident_cd INTEGER, fetch next block: start at:213 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:216 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> bene_age_cat_cd INTEGER, mapi_query_part:26: bene_age_cat_cd INTEGER, fetch next block: start at:218 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:221 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_icd9_dgns_cd VARCHAR(255), mapi_query_part:37: car_line_icd9_dgns_cd VARCHAR(255), fetch next block: start at:223 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:226 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_hcpcs_cd VARCHAR(255), mapi_query_part:33: car_line_hcpcs_cd VARCHAR(255), fetch next block: start at:228 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:231 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_betos_cd VARCHAR(255), mapi_query_part:33: car_line_betos_cd VARCHAR(255), fetch next block: start at:233 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:236 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_srvc_cnt INTEGER, mapi_query_part:28: car_line_srvc_cnt INTEGER, fetch next block: start at:238 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:241 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_prvdr_type_cd INTEGER, mapi_query_part:33: car_line_prvdr_type_cd INTEGER, fetch next block: start at:243 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:246 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_cms_type_srvc_cd VARCHAR(255), mapi_query_part:41: car_line_cms_type_srvc_cd VARCHAR(255), fetch next block: start at:248 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:251 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_line_place_of_srvc_cd INTEGER, mapi_query_part:36: car_line_place_of_srvc_cd INTEGER, fetch next block: start at:253 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:256 got next block: length:0 text: got complete block: text:☺ read_line:☺ more> car_hcpcs_pmt_amt INTEGER mapi_query_part:27: car_hcpcs_pmt_amt INTEGER fetch next block: start at:258 got next block: length:3 text:☺☻ got complete block: text:☺☻ read_line:☺☻ fetch next block: start at:261 got next block: length:0 text: got complete block: text:☺ read_line:☺ more>) ; mapi_query_part:4:) ; fetch next block: start at:263 got next block: length:3 text:&3 got complete block: text:&3 read_line:&3 allocating new result set fetch next block: start at:266 got next block: length:0 text: got complete block: text:☺ read_line:☺ operation successful (276.500ms) closing result set sql> fetch next block: start at:268 got next block: length:0 text: got complete block: text:☺ read_line:☺ sql>COPY 9676440 offset 2 records INTO mytable3 FROM 'v:\temp\2008_BSA_Carrier_L ine_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL AS '' ; mapi_query_part:141:COPY 9676440 offset 2 records INTO mytable3 FROM 'v:\temp\20 08_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL AS '' ; fetch next block: start at:270 got next block: length:14 text:&2 9676439 -1 got complete block: text:&2 9676439 -1 read_line:&2 9676439 -1 allocating new result set fetch next block: start at:284 got next block: length:0 text: got complete block: text:☺ read_line:☺ 9676439 affected rows (2m 14s) closing result set sql>

2 2

TPCH Throughput/latency for MonetDB
by Hassan, Ahmad 12 Feb '13

12 Feb '13

Hi, I intend to run TPCH benchmark on MonetDB. I have executed one iteration of benchmark through run.all script provided under sql/benchmarks/tpch. Please may I know if there is a script or framework available to run tpch benchmark for 'X' duration and get throughput and latency numbers for each query? Second, I want to generated data with big scale factor. I searched monetdb mailing list and found out that DBGEN should be used for that. As there is no specific DBGEN provided by monetdb so I have downloaded from http://www.tpc.org/tpch/ . But please let me know which of the following database shall I select while building DBGEN. Official DBGEN supports the following database options: INFORMIX, DB2, TDAT (Teradata), SQLSERVER, SYBASE, ORACLE, VECTORWISE Thanks for the help Kind Regards, Ahmad

1 0

monetdb status health
by Tapomay Dey 12 Feb '13

12 Feb '13

My questions are simple: what causes crashes? what is health? how do we stop health from degrading? Following is the status of my db- msearch_stats_db: database name: msearch_stats_db state: running locked: no scenarios: mal sql msql start count: 140 stop count: 1 crash count: 138 current uptime: 1m 49s average uptime: 15m 33s maximum uptime: 15m 33s minimum uptime: 15m 33s last start with crash: 2013-02-10 17:32:36 last start: 2013-02-10 17:32:47 last stop: 2013-02-06 11:27:15 average of crashes in the last start attempt: 0 average of crashes in the last 10 start attempts: 0.90 average of crashes in the last 30 start attempts: 0.97 Regards, Tapomay.

6 14