- users-list - monetdb.org

[MonetDB-users] Error on "rank() over (order by sum(.."
by Makoto YUI 04 Jan '10

04 Jan '10

Hi, The following query yields "SELECT: subquery result missing" error on Nov2009-SP1. select s_name, sum(score), rank() over (order by sum(score) desc) from score_table group by s_name -- preparation create table score_table ( s_name varchar(20), subject varchar(10), score int ); insert into score_table values('foo','english',70); insert into score_table values('foo','history',50); insert into score_table values('foo','math',60); insert into score_table values('bar','english',45); insert into score_table values('bar','history',75); It seems allowed to use aggregation functions in "over(..)" in other databases. http://www.google.com/search?q="rank()+over+(order+by+sum(" Thanks, Makoto

1 0

[MonetDB-users] Limitation in "create table .. as subquery"
by Makoto YUI 04 Jan '10

04 Jan '10

Hello, create table t1 (f1 int); insert into t1 values (1); insert into t1 values (2); create table t2 as (select * from t1 limit 1) with data; The above "create table" caused the following syntax error on the Limit clause. syntax error, unexpected LIMIT, expecting INTERSECT or EXCEPT or UNION or ')' in: "create table t2 as (select * from t1 limit" Is this an expected behavior? This "subquery" issue might be related. http://sourceforge.net/tracker/?func=detail&atid=482468&aid=2620437&group_i… I'm using Nov2009-SP1 on Linux. Thanks, Makoto

3 7

[MonetDB-users] Problem with BSS initialisation.
by Guillaume Yziquel 03 Jan '10

03 Jan '10

Hello. I've spent quite some time lately debugging my issue with OCaml binding of MonetDB libraries: http://www.mail-archive.com/caml-list@yquem.inria.fr/msg05449.html It seems that the BSS is not properly initialised to 0 when dynamically loaded. It seems that the code in mal_box.c relies on the fact that BSS is initialised to 0 when loaded. I'm still trying to figure out how exactly is the libmonetdb5.so library loaded. This is still an obscure point. ltrace did not provide useful information. Advice welcome. -- Guillaume Yziquel http://yziquel.homelinux.org/

2 2

[MonetDB-users] Multiple core usage on Windows
by Alex Bo. 03 Jan '10

03 Jan '10

Hi, Does MonetDB split a single query plan over multiple CPU cores when its possible? (maybe the DataFlow optimizer?) For example, the following query could be executed by all cores in parallel: SELECT field1,SUM(field2) FROM Table1 GROUP BY field1 When i tried to see if it does, i got some weird results: (I am running MonetDB on Windows, on a quad core machine) When I set '--set gdk_nr_threads=1', queries never seem to use more than 25%. (seems logical since only one CPU core is being deployed) When I set '--set gdk_nr_threads=2', queries use up to 50% CPU, but the query is ~15% slower. When I set '--set gdk_nr_threads=4', queries use up to 98% CPU, but the query is take twice as long as with 1 thread. So, my initial assumption that more CPU utilization (more cores over the same query) will result faster query results (where applicable) is wrong. Can it be something specific to the windows platform? or maybe single query execution over multiple cores doesn't work without a specific optimizer flag enabled?... or maybe is it just a bug... Thanks. -- View this message in context: http://old.nabble.com/Multiple-core-usage-on-Windows-tp27002955p27002955.ht… Sent from the monetdb-users mailing list archive at Nabble.com.

2 1

Re: [MonetDB-users] segfault with monetdb_sql().
by Guillaume Yziquel 02 Jan '10

02 Jan '10

Martin Kersten a écrit : >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 0x2aaaaf66d910 (LWP 4061)] >>> 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5 > > i miss here the line number, seems that is ubunti specific > you can do > print i > print box[i] > print name Providing debian packages of libraries with debugging symbols would be great. > i suspect box[i] is not properly initialized to 0 I'll try to check that. >>> (gdb) backtrace >>> #0 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5 > this gives one hint, it is likely passed without name causing idcmp to fail >>> #1 0x00002aaaac677086 in openBox () from /usr/lib/libmonetdb5.so.5 >>> #2 0x00002aaab7a51cbb in MTIMEprelude () from > > happens while loading the data/time module. It initializes the "time" > module Should I assume that the mtime.mal + lib_mtime.so is the first one to be loaded? Just to know if some dynamic linking successfully happened before or not. >>> /usr/lib/MonetDB5/lib/lib_mtime.so >>> #3 0x00002aaaac6826cf in ?? () from /usr/lib/libmonetdb5.so.5 >>> #4 0x00002aaaac68b2a0 in runMAL () from /usr/lib/libmonetdb5.so.5 >>> #5 0x00002aaaac67cac7 in MALengine () from /usr/lib/libmonetdb5.so.5 >>> #6 0x00002aaaac67d5f6 in malBootstrap () from /usr/lib/libmonetdb5.so.5 >>> #7 0x00002aaaac669f75 in mal_init () from /usr/lib/libmonetdb5.so.5 >>> #8 0x00002aaaab91ef60 in ?? () from /usr/lib/libembeddedsql5.so >>> #9 0x00002aaaab39b73a in start_thread () from /lib/libpthread.so.0 >>> #10 0x00002aaaab67c69d in clone () from /lib/libc.so.6 >>> #11 0x0000000000000000 in ?? () >>> (gdb) >> >> Please tell me what else could be useful. > > This was already useful, because i added two additional defense lines > to capture improperly set environments. OK. I'll check. >>> I am not an CAML expert, but i guess there may be potential issues >>> in location and dynamic loading of the necessary libraries. >>> Where does CAML get the libraries from? >> >> As a rather general statement, dynamic loading is supported within >> OCaml world. I'm not so sure how this works when it is C code that >> triggers dynamic loading, with OCaml in bytecode mode... > > I have added some extra code to make failing loads more visible. > In general, it seems that the modules are not found at the location I'll ask on the OCaml list for that. >> I would like to pinpoint the segfault more precisely in order to go >> back to the OCaml mailing list about potential dynamic loading issues. > I think it can not find your libraries > > set the variable gdk_debug=10 this will show you the environment > settings as seen upon start. Including the location where it expect > database and libraries to recide. Will do that. However, I believe it is not a problem of location, as this works out fine when the OCaml binding is compiled to native code. All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/

2 4

[MonetDB-users] (no subject)
by Zoltan Tomory 30 Dec '09

30 Dec '09

Hi everybody, Forgive the reference to a cartoon, but it seems strangely on topic ... >There's a wonderful comic strip on the web called xkcd; I don't know if you've heard of it. I have to share this one with you. It's called "Exploits of a mother": > >http://xkcd.com/327/ Happy New Year! Zoltan Tomory zoltan.tomory(a)mobot.org

1 0

Re: [MonetDB-users] segfault with monetdb_sql().
by Guillaume Yziquel 29 Dec '09

29 Dec '09

Hello. As some discussion had gone off-list, here's some relevant background: The OCaml binding works when the OCaml library is compiled to native code, and it segfaults when the OCaml library is compiled to bytecode. Martin Kersten a écrit : > > What is the gdb stack trace of the processes involved? segfaults are only > analysed that way. Quite new to gdb, so I do not know if this is what you've asked for: > gdb --args ocamlrun test/monetdb_sql.byte > GNU gdb (GDB) 7.0-debian > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/bin/ocamlrun...(no debugging symbols found)...done. > (gdb) run > Starting program: /usr/bin/ocamlrun test/monetdb_sql.byte > [Thread debugging using libthread_db enabled] > [New Thread 0x2aaaaf66d910 (LWP 4061)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x2aaaaf66d910 (LWP 4061)] > 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5 > (gdb) backtrace > #0 0x00002aaaac676de3 in findBox () from /usr/lib/libmonetdb5.so.5 > #1 0x00002aaaac677086 in openBox () from /usr/lib/libmonetdb5.so.5 > #2 0x00002aaab7a51cbb in MTIMEprelude () from /usr/lib/MonetDB5/lib/lib_mtime.so > #3 0x00002aaaac6826cf in ?? () from /usr/lib/libmonetdb5.so.5 > #4 0x00002aaaac68b2a0 in runMAL () from /usr/lib/libmonetdb5.so.5 > #5 0x00002aaaac67cac7 in MALengine () from /usr/lib/libmonetdb5.so.5 > #6 0x00002aaaac67d5f6 in malBootstrap () from /usr/lib/libmonetdb5.so.5 > #7 0x00002aaaac669f75 in mal_init () from /usr/lib/libmonetdb5.so.5 > #8 0x00002aaaab91ef60 in ?? () from /usr/lib/libembeddedsql5.so > #9 0x00002aaaab39b73a in start_thread () from /lib/libpthread.so.0 > #10 0x00002aaaab67c69d in clone () from /lib/libc.so.6 > #11 0x0000000000000000 in ?? () > (gdb) Please tell me what else could be useful. > I am not an CAML expert, but i guess there may be potential issues > in location and dynamic loading of the necessary libraries. > Where does CAML get the libraries from? As a rather general statement, dynamic loading is supported within OCaml world. I'm not so sure how this works when it is C code that triggers dynamic loading, with OCaml in bytecode mode... I would like to pinpoint the segfault more precisely in order to go back to the OCaml mailing list about potential dynamic loading issues. > We can help (on Xmas days) only with proper output. The level of > programming > calls for expertise in dealing with C debuggers, dynamic loaders, and > thread > management. Guessing does not bring us further. You have to use the > right tools. OK. This is always a good opportunity to learn more about C world... Thanks for pointing out the right tools. All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/

1 0

[MonetDB-users] Instalation prob. in Ubuntu
by Rui Anastácio 28 Dec '09

28 Dec '09

Hi, I'm trying to install monetdb in my Linux Ubuntu 9.10 Karmik and have followed the instructions but have this dependency problem: monetdb-geom-dev: Depends: libmonetdb5-geom0 not installable monetdb-testing: Depends: python-monetdb not installable Regards Rui Anastácio

1 0

[MonetDB-users] Updating a single column by means of a secondary table
by Stefan de Konink 27 Dec '09

27 Dec '09

Hi, I have the following issue; I would like to update a new column with respect to old data. In essence this would be the idea that I want to do: update anbikvk set intrekking = (select intrekking from anbi_update where anbi_update.naam = anbikvk.naam); The above way does not work, the only other way that I would know would involve a temporary table. Could anyone elaborate how this is possible using the update statement? Stefan

3 3

[MonetDB-users] segfault with monetdb_sql().
by Guillaume Yziquel 27 Dec '09

27 Dec '09

Hello. I've been having segfaults when using the following wrapper code. (Do not pay attention to the CAML* macros, and String_val is a macro that converts a string in OCaml to a C string, and Val_ptr is a function that wraps up a pointer into OCaml.) > CAMLprim value ml_monetdb_sql (value ml_dbfarm, value ml_dbname) { > CAMLparam2(ml_dbfarm, ml_dbname); > CAMLlocal1(result); > char * dbfarm; > char * dbname; > dbfarm = String_val(ml_dbfarm); > dbname = String_val(ml_dbname); > Mapi mapi = monetdb_sql(dbfarm, dbname); > result = Val_ptr(mapi); > CAMLreturn(result); > } I'm calling this code with dbfarm and dbname set to a place I can write to, and that does not contain folders, files, or data at the time the function is called from OCaml code. When executing the following piece of code from the OCaml toplevel > #use "topfind";; > #thread;; > #load "monetDB5.cma";; > > open MonetDB5;; > let mapi = monetdb_sql "/home/yziquel/sandbox/monetdb" "testdb";; I get a segfault arising from monetdb's shared libraries (I'm using the Debian packages on a 64 bits platform): > yziquel@seldon:~/git/ocaml-monetdb5$ ocaml -init ocamlinit > Objective Caml version 3.11.1 > > Findlib has been successfully loaded. Additional directives: > #require "package";; to load a package > #list;; to list the available packages > #camlp4o;; to load camlp4 (standard syntax) > #camlp4r;; to load camlp4 (revised syntax) > #predicates "p,q,...";; to set these predicates > Topfind.reset();; to force that packages will be reloaded > #thread;; to enable threads > > /usr/lib/ocaml/threads: added to search path > /usr/lib/ocaml/unix.cma: loaded > /usr/lib/ocaml/threads/threads.cma: loaded > Erreur de segmentation Here at the last line... Looking at the code in monetdb-sql-2.34.2/src/backends/monet5/embeddedclient.c.in I'm unable to determine if the segault comes from the invocation of pthread_create or from the invocation of mapi_start_talking. > Mapi > monetdb_sql(char *dbfarm, char *dbname) > { > Mapi mid; > pthread_t sqlthread; > stream **server; > > int len = mo_builtin_settings(&embedded_set); > > /* needed, to prevent the MonetDB config file to be used */ > len = mo_add_option(&embedded_set, len, opt_config, "prefix", MONETDB5_PREFIX); > len = mo_add_option(&embedded_set, len, opt_config, "config", MONETDB5_CONFFILE); > len = mo_add_option(&embedded_set, len, opt_config, "monet_mod_path", > "@QXlibdir@@QDIRSEP@MonetDB5@PATHSEP@@QXlibdir@@QDIRSEP@MonetDB5@QDIRSEP@lib@PATHSEP@@QXlibdir@@QDIRSEP@MonetDB5@QDIRSEP@bin"); > > embedded_len = mo_system_config(&embedded_set, len); > embedded_len = mo_add_option(&embedded_set, embedded_len, opt_cmdline, "gdk_dbfarm", dbfarm); > embedded_len = mo_add_option(&embedded_set, embedded_len, opt_cmdline, "gdk_dbname", dbname); > > server = mapi_embedded_init(&mid,"sql"); > > pthread_create(&sqlthread, NULL, start_sql_server, (void *) server); > > mapi_start_talking(mid); > > return mid; > } Could someone give me hints as to what is going wrong here? All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/

3 6