July 2014 - users-list

[MonetDB-users] Books CDs
by CHARTS LICENSING 11 Aug '24

11 Aug '24

Everything you want to know this dynamic artist check. At blueberry hills duck, roomfull story gtgt getting. Intriguing, life in biography. Here music looking for lyrics maybe, youre find which! Download free wallpapers featuring business cmg worldwide is exclusive. Videos latest products been easier. Exclusive estate we consider request use name voice, image. List covered berries charts licensing message! Reelin and rockin about, has everything you? Many exciting, photos him stage click! Artist check, out some quotes read all intriguing. It alive he, did on occasion birthday wednesday? Has everything you want to know this? Quotes read all intriguing life, in biography or. Gtgt getting licks years reelin and. Click here, music looking for lyrics maybe, youre. News celebrates his th rock will never! Chuck berry news celebrates his th rock, will. Browse through many exciting, photos him stage click here. He did on occasion birthday wednesday night at blueberry. Wallpapers featuring business cmg worldwide. Worldwide is exclusive estate we consider, request use name. Want to know this dynamic artist check out. Awards fast, facts clips list covered. Music looking for lyrics maybe youre. Message board downloads tour dates fan, club inquiries. Other sites, download free wallpapers featuring, business cmg worldwide. Request use, name, voice.

2 1

Multi-column update based on joined table
by Lee Hachadoorian 11 Aug '24

11 Aug '24

I need to update multiple columns (~250) from one table to another based on a two-column key. In Postgres I would write this using the FROM clause, but since MonetDB doesn't support the FROM clause, I've successfully updated one column with: UPDATE census.acs2010_5yr SET b07401001 = ( SELECT CAST(b07401001 AS int) FROM acs2010_5yr.tmp_seq0001 WHERE acs2010_5yr.stusab = tmp_seq0001.stusab AND acs2010_5yr.logrecno = tmp_seq0001.logrecno ); My question is whether there is any benefit to writing a multiple column update into a single UPDATE statement: UPDATE target_table SET column1 = (SELECT column1 FROM source_table WHERE target_table.key = source_table.key), column2 = (SELECT column2 FROM source_table WHERE target_table.key = source_table.key), ..., columnN = (SELECT columnN FROM source_table WHERE target_table.key = source_table.key); On Postgres I believe the multi-column update using a table join would only have to do the sequential scan of each table once, but with the necessity of sub-selects in MonetDB, what is the backend doing? Is it already doing an index scan once for each row in the single column case, then doing it once for each row * column in the multi-column case? Best, --Lee -- Lee Hachadoorian Asst Professor of Geography, Dartmouth College http://freecity.commons.gc.cuny.edu/

3 3

[MonetDB-users] XQuery API and XLink/XUpdate support
by Alexandra Mart�nez 27 Jun '24

27 Jun '24

Hello all, I was wondering if there is any documentation about the API for XQuery (i.e., how to write xqueries from a Java program). Also, I am interested in using some features of XLink and XUpdate on top of my XML database. Is support for any of these in progress? Thanks in advance, Alexandra ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

4 3

[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

Connection Reset(mserver still alive?)
by Ali Salem 06 Aug '14

06 Aug '14

Hello, I have recently started using MonetDB for a BI project, and it's doing pretty well. However, I receive a connection reset error each time I run an ETL process (I use Pentaho PDI) to populate my dimensional schema. This error is reported by the MonetDB JDBC driver *Connection reset(mserver still alive?)* This usually happens after a random amount of time, 30 min, 45 min, 1 hour, etc. Any pointers related to this would be very helpful. Specs ------- Ubuntu 12.04 8 GB Ram 500 GB Space Pentaho PDI (community edition) Monetdb5 (installed using apt-get) Thank you.

4 6

Adding conditions slows query 1000x
by Dennis Pallett 31 Jul '14

31 Jul '14

Hi all, When I run the following query the results are computed extremely fast (within 5 ms): SELECT id_str, len,coordinates_x,coordinates_y FROM uk_neogeo_sorted WHERE coordinates_x >= 0.0 AND coordinates_x <= 22.499999996867977 LIMIT 100; However if I add additional conditions to the query so that it becomes the following: SELECT id_str,len,coordinates_x,coordinates_y FROM uk_neogeo_sorted WHERE coordinates_x >= 0.0 AND coordinates_x <= 22.499999996867977 AND coordinates_y >= 0.0 AND coordinates_y <= 61.60639636617352 LIMIT 100; The time it takes to compute the results is approximately 1000x bigger (i.e. 5 seconds). Clearly the additional conditions on the coordinates_y column is forcing MonetDB to take a different query strategy but I don't know how I can solve this. In Postgres I would make sure there is an index on the (coordinates_x, coordinates_y) column but this doesn't seem to have any effect with MonetDB. I've attached traces of both queries. There are approximately 11 million rows in the table. Can anyone tell me why there is such a huge difference in query execution time and how I can prevent it? Best regards, Dennis Pallett

5 15

Announcement: New Jan2014-SP3 Bugfix release of MonetDB suite
by Sjoerd Mullender 31 Jul '14

31 Jul '14

The MonetDB team at CWI/MonetDB BV is pleased to announce the Jan2014-SP3 bugfix 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/>. Jan 2014-SP3 bugfix release Build Environment * Fix configure to continue without Python if the python binary is too old. This instead of always aborting configure if python happens to be too old. Bug Fixes * 3487: dead link to "Professional services" * 3500: MonetDB driver wants an empty string for SQLTables and SQLColumns API calls, where other drivers expect NULL * 3514: mserver5 crash due (assertion failure in gdk_select.c) * 3515: mserver5 crash due (assertion failure in gdk_bat.c) * 3519: Uppercase TRUE/FALSE strings cannot be converted to boolean values

1 0

High amount of VIRT and high amount of writing
by amihay gonen 29 Jul '14

29 Jul '14

Hi all , we are trying to compare oracle vs monetdb. the query we are try to run is : select count( client_code_new ) as s from ( SELECT t.client_code_new, t.bank, t.branch_new, t.ACCOUNT, t.instrument_ident, MAX (t.system_code) FROM transactions t left outer join ( SELECT c.linked_open_transaction_new as linked_open_transaction_new FROM calculated_taxs c GROUP BY c.linked_open_transaction_new) c_temp on t.transaction_no = c_temp.linked_open_transaction_new join clients_list cl on cl.client_code = t.client_code_new AND cl.branch = t.branch_new WHERE t.opg_cls = 'O' AND (t.close_trans_disregard_balance_new) =0 and new_system_code = 1 GROUP BY t.client_code_new, t.bank, t.branch_new, t.ACCOUNT, t.instrument_ident) a ; tables sizes are: transactions = 103M rows calculated_taxs= 79M rows The query is taking 1min to run. we've notice that during the query run the VIRT column (from top utility) is become very high 10G , and during the we see extensive write to disk . why does monet is do so much writing ? thanks, amihay bellow is output of minimal_pipe optimizer +------------------------------------------------------------------------------------------------------------------------------------------------------------+ | mal | +============================================================================================================================================================+ | function user.s4_3{autoCommit=true}(A0:str,A1:int,A2:int):void; | | X_5 := sql.mvc(); | | X_6:bat[:oid,:oid] := sql.tid(X_5,"sys","clients_list"); | | X_9 := sql.bind(X_5,"sys","clients_list","client_code",0); | | (X_12,r1_12) := sql.bind(X_5,"sys","clients_list","client_code",2); | | X_15 := sql.bind(X_5,"sys","clients_list","client_code",1); | | X_17 := sql.delta(X_9,X_12,r1_12,X_15); | | X_18 := algebra.leftfetchjoin(X_6,X_17); | | X_19 := batcalc.int(X_18); | | X_20:bat[:oid,:wrd] := batcalc.hash(X_19); | | X_23 := calc.int(22); | | X_25 := sql.bind(X_5,"sys","clients_list","branch",0); | | (X_27,r1_27) := sql.bind(X_5,"sys","clients_list","branch",2); | | X_29 := sql.bind(X_5,"sys","clients_list","branch",1); | | X_30 := sql.delta(X_25,X_27,r1_27,X_29); | | X_31 := algebra.leftfetchjoin(X_6,X_30); | | X_32:bat[:oid,:wrd] := mkey.bulk_rotate_xor_hash(X_20,X_23,X_31); | | X_33:bat[:oid,:int] := bat.new(nil:oid,nil:int); | | X_36:bat[:oid,:oid] := sql.tid(X_5,"sys","transactions"); | | X_38 := sql.bind(X_5,"sys","transactions","close_trans_disregard_balance_new",0); | | (X_40,r1_40) := sql.bind(X_5,"sys","transactions","close_trans_disregard_balance_new",2); | | X_43 := sql.bind(X_5,"sys","transactions","close_trans_disregard_balance_new",1); | | X_44 := sql.delta(X_38,X_40,r1_40,X_43); | | X_45 := algebra.leftfetchjoin(X_36,X_44); | | X_46 := A1; | | X_47 := sql.bind(X_5,"sys","transactions","new_system_code",0); | | (X_50,r1_50) := sql.bind(X_5,"sys","transactions","new_system_code",2); | | X_53 := sql.bind(X_5,"sys","transactions","new_system_code",1); | | X_55 := sql.delta(X_47,X_50,r1_50,X_53); | | X_56 := algebra.leftfetchjoin(X_36,X_55); | | X_57 := A2; | | X_58 := sql.bind(X_5,"sys","transactions","opg_cls",0); | | (X_60,r1_60) := sql.bind(X_5,"sys","transactions","opg_cls",2); | | X_62 := sql.bind(X_5,"sys","transactions","opg_cls",1); | | X_63 := sql.delta(X_58,X_60,r1_60,X_62); | | X_64 := algebra.leftfetchjoin(X_36,X_63); | | X_65 := A0; | | X_66 := algebra.subselect(X_64,X_65,X_65,true,true,false); | | X_69 := algebra.subselect(X_56,X_66,X_57,X_57,true,true,false); | | X_70 := algebra.subselect(X_45,X_69,X_46,X_46,true,true,false); | | X_71 := sql.bind(X_5,"sys","transactions","transaction_no",0); | | (X_74,r1_74) := sql.bind(X_5,"sys","transactions","transaction_no",2); | | X_77 := sql.bind(X_5,"sys","transactions","transaction_no",1); | | X_78 := sql.delta(X_71,X_74,r1_74,X_77); | | X_79 := algebra.leftfetchjoin(X_36,X_78); | | X_80 := algebra.leftfetchjoin(X_70,X_79); | | X_81:bat[:oid,:oid] := sql.tid(X_5,"sys","calculated_taxs"); | | X_83 := sql.bind(X_5,"sys","calculated_taxs","linked_open_transaction_new",0); | | (X_86,r1_86) := sql.bind(X_5,"sys","calculated_taxs","linked_open_transaction_new",2); | | X_89 := sql.bind(X_5,"sys","calculated_taxs","linked_open_transaction_new",1); | | X_91 := sql.delta(X_83,X_86,r1_86,X_89); | | X_92 := algebra.leftfetchjoin(X_81,X_91); | | (X_93,r1_93,r2_93) := group.subgroupdone(X_92); | | X_96 := algebra.leftfetchjoin(r1_93,X_92); | | X_97 := batcalc.lng(X_96); | | (X_98,r1_98) := algebra.join(X_80,X_97); | | X_100 := sql.bind(X_5,"sys","transactions","client_code_new",0); | | (X_102,r1_102) := sql.bind(X_5,"sys","transactions","client_code_new",2); | | X_104 := sql.bind(X_5,"sys","transactions","client_code_new",1); | | X_106 := sql.delta(X_100,X_102,r1_102,X_104); | | X_107 := algebra.leftfetchjoin(X_36,X_106); | | X_108 := algebra.leftfetchjoin(X_70,X_107); | | X_109 := algebra.leftfetchjoin(X_98,X_108); | | X_110 := bat.append(X_33,X_109,true); | | X_112 := bat.mirror(X_80); | | X_113 := algebra.tdiff(X_112,X_98); | | X_114 := algebra.leftfetchjoin(X_113,X_108); | | X_115 := bat.append(X_110,X_114,true); | | X_116:bat[:oid,:wrd] := batcalc.hash(X_115); | | X_119 := calc.int(22); | | X_121:bat[:oid,:int] := bat.new(nil:oid,nil:int); | | X_124 := sql.bind(X_5,"sys","transactions","branch_new",0); | | (X_128,r1_128) := sql.bind(X_5,"sys","transactions","branch_new",2); | | X_131 := sql.bind(X_5,"sys","transactions","branch_new",1); | | X_133 := sql.delta(X_124,X_128,r1_128,X_131); | | X_134 := algebra.leftfetchjoin(X_36,X_133); | | X_135 := algebra.leftfetchjoin(X_70,X_134); | | X_136 := algebra.leftfetchjoin(X_98,X_135); | | X_137 := bat.append(X_121,X_136,true); | | X_138 := algebra.leftfetchjoin(X_113,X_135); | | X_139 := bat.append(X_137,X_138,true); | | X_140:bat[:oid,:wrd] := mkey.bulk_rotate_xor_hash(X_116,X_119,X_139); | | (X_141,r1_141) := algebra.join(X_32,X_140); | | X_143 := algebra.leftfetchjoin(X_141,X_19); | | X_144 := algebra.leftfetchjoin(r1_141,X_115); | | X_145:bat[:oid,:bit] := batcalc.==(X_143,X_144); | | X_147 := calc.bit(true); | | X_149 := algebra.subselect(X_145,X_147,X_147,true,true,false); | | X_151 := algebra.leftfetchjoin(X_149,X_141); | | X_152 := algebra.leftfetchjoin(X_151,X_31); | | X_153 := algebra.leftfetchjoin(X_149,r1_141); | | X_154 := algebra.leftfetchjoin(X_153,X_139); | | X_155:bat[:oid,:bit] := batcalc.==(X_152,X_154); | | X_157 := calc.bit(true); | | X_158 := algebra.subselect(X_155,X_157,X_157,true,true,false); | | X_159 := algebra.leftfetchjoin(X_158,X_153); | | X_160:bat[:oid,:dbl] := bat.new(nil:oid,nil:dbl); | | X_163 := sql.bind(X_5,"sys","transactions","bank",0); | | (X_168,r1_168) := sql.bind(X_5,"sys","transactions","bank",2); | | X_171 := sql.bind(X_5,"sys","transactions","bank",1); | | X_173 := sql.delta(X_163,X_168,r1_168,X_171); | | X_174 := algebra.leftfetchjoin(X_36,X_173); | | X_175 := algebra.leftfetchjoin(X_70,X_174); | | X_176 := algebra.leftfetchjoin(X_98,X_175); | | X_177 := bat.append(X_160,X_176,true); | | X_178 := algebra.leftfetchjoin(X_113,X_175); | | X_179 := bat.append(X_177,X_178,true); | | X_180 := algebra.leftfetchjoin(X_159,X_179); | | X_181:bat[:oid,:str] := bat.new(nil:oid,nil:str); | | X_183 := sql.bind(X_5,"sys","transactions","account",0); | | (X_185,r1_185) := sql.bind(X_5,"sys","transactions","account",2); | | X_187 := sql.bind(X_5,"sys","transactions","account",1); | | X_188 := sql.delta(X_183,X_185,r1_185,X_187); | | X_189 := algebra.leftfetchjoin(X_36,X_188); | | X_190 := algebra.leftfetchjoin(X_70,X_189); | | X_191 := algebra.leftfetchjoin(X_98,X_190); | | X_192 := bat.append(X_181,X_191,true); | | X_194 := algebra.leftfetchjoin(X_113,X_190); | | X_195 := bat.append(X_192,X_194,true); | | X_196 := algebra.leftfetchjoin(X_159,X_195); | | X_197:bat[:oid,:str] := bat.new(nil:oid,nil:str); | | X_199 := sql.bind(X_5,"sys","transactions","instrument_ident",0); | | (X_204,r1_204) := sql.bind(X_5,"sys","transactions","instrument_ident",2); | | X_207 := sql.bind(X_5,"sys","transactions","instrument_ident",1); | | X_209 := sql.delta(X_199,X_204,r1_204,X_207); | | X_210 := algebra.leftfetchjoin(X_36,X_209); | | X_211 := algebra.leftfetchjoin(X_70,X_210); | | X_212 := algebra.leftfetchjoin(X_98,X_211); | | X_213 := bat.append(X_197,X_212,true); | | X_214 := algebra.leftfetchjoin(X_113,X_211); | | X_215 := bat.append(X_213,X_214,true); | | X_216 := algebra.leftfetchjoin(X_159,X_215); | | X_217 := algebra.leftfetchjoin(X_159,X_115); | | X_218 := algebra.leftfetchjoin(X_159,X_139); | | (X_219,r1_219,r2_219) := group.subgroup(X_218); | | (X_222,r1_222,r2_222) := group.subgroup(X_217,X_219); | | (X_225,r1_225,r2_225) := group.subgroup(X_216,X_222); | | (X_228,r1_228,r2_228) := group.subgroup(X_196,X_225); | | (X_231,r1_231,r2_231) := group.subgroupdone(X_180,X_228); | | X_234 := algebra.leftfetchjoin(r1_231,X_217); | | X_235 := algebra.selectNotNil(X_234); | | X_236 := aggr.count(X_235); | | sql.exportValue(1,".L2","s","wrd",64,0,6,X_236,""); | | end s4_3; | | # querylog.define("explain \nselect count( client_code_new ) as s from \n(\n select t.client_code_new, t.bank, t.branch_new, t.account, t. | : instrument_ident, max (t.system_code)\n from transactions t left outer join \n ( select c.linked_open_transaction_new as linked_open_transa : : ction_new from calculated_taxs c group by c.linked_open_transaction_new) c_temp\n on t.transaction_no = c_temp.linked_open_transaction_new \njoin cli : : ents_list cl on cl.client_code = t.client_code_new and cl.branch = t.branch_new\n where t.opg_cls = \\'O\\' and (t.close_trans_disregard_balance_new) = : : 0 and new_system_code = 1 \n group by t.client_code_new, t.bank, t.branch_new, t.account, t.instrument_ident) a : : ;","minimal_pipe") : +------------------------------------------------------------------------------------------------------------------------------------------------------------+

2 1

monetdb is slow to backup
by Pierre-Adrien Coustillas 29 Jul '14

29 Jul '14

Hello, I'm used to save monetdb using msqldump : msqldump --database=base --table=table > backup.sql This command takes 30 minutes to backup 6 GB , but 4 minutes to restore. How can I increase backup speed ? Thanks Pierre -- 1G6 52 route de bischwiller 67300 Schiltigheim Société de Services et de Formations en Logiciels Libres http://1g6.biz Tél : 06 64 63 70 35

3 5

GDKerror when using COPY INTO sql commands
by Mahmut Uludag 25 Jul '14

25 Jul '14

Hi, We update our MonetDB databases using COPY INTO commands, we recently have started to get errors similar to the following error. GDKerror:!ERROR: GDKload: cannot read: name=13/52/135274, ext=theap, 56932 bytes missing. !OS: No such file or directory GDKload: cannot read: name=13/56/135610, ext=theap, 906 bytes missing. !OS: No such file or directory Deleting and recreating the tables and the schema haven't helped. If we create a new table with a table name not used in the past then we are able to use COPY INTO commands to update the new table. It is also possible to update the broken tables using 'INSERT INTO' commands. We see the problem only when we use COPY INTO commands. We use MonetDB Jan2014-SP1 release. We have 3 database nodes that 2 of them doesn't show this error. Any help much appreciated. We also don't know yet why we have started getting this error, any notes on how one can start getting this error would also be helpful. Mahmut Uludag

2 3