- users-list - monetdb.org

[MonetDB-users] Compilation issue on OS X Panther
by Fabian 20 Mar '05

20 Mar '05

(I am not the one with the problem here, but reporting on behalf to stick to the protocol. Please ignore your user agent's default reply to address and send replies to the list, not to me.) The following build error appears for a user that compiles on a Mac: gcc -g -O2 -std=c99 -Wall -W -Werror-implicit-function-declaration -Werror -Wno-format -Wno-unused-function -Wno-unused-label -Wno-uninitialized -D_REENTRANT -o .libs/MapiClient MapiClient.o ReadlineTools.o -L/sw/lib ./.libs/libMapi.dylib /Users/rvjansen/Desktop/MonetDB/src/common/.libs/libstream.dylib -lreadline ../../../common/.libs/libmutils.dylib ../../../common/.libs/libstream.dylib /Users/rvjansen/Desktop/MonetDB/src/common/.libs/libmutils.dylib -lz /sw/lib/libiconv.dylib ld: Undefined symbols: _BZ2_bzclose _BZ2_bzflush _BZ2_bzopen _BZ2_bzread _BZ2_bzwrite make[7]: *** [MapiClient] Error 1 make[6]: *** [all] Error 2 make[5]: *** [all-recursive] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 The user's tools versions: automake 1.9.3 aclocal 1.9.3 autoconf 2.59 libtool ? (there is no --version: default Apple distribution one)

3 9

[MonetDB-users] [Fwd: Re: cvs lock]
by Fabian 20 Mar '05

20 Mar '05

Here find attached the config.status file of the OSX compilation issue. about the mailing list settings stuff (which should be off the list, IMHO): there is a weird distinction between what developers think is useful and what users think is useful. For the sourceforge/Mailman case it seems to me that the former one is considered instead of the latter, which is -- if you expect users to use it -- a wrong assumption. Since SF is made for developers (you have to have a developers account for instance), SF is clearly NOT the place for user interaction. Proof of this theorem can be found in many projects that host a forum like structure on their main website, that often allows guest posting, which is clearly geared towards user usability. (how big do you want to have the barrier that prevents someone from reporting a problem today?)

1 0

[MonetDB-users] SQL Support
by Smits.Dolf 08 Mar '05

08 Mar '05

Hi, I downloaded and installed version 4.6 and am adapting some SQL scripts to the preferred syntax from MonetDB. However, I cannot find any document about what features are implemented, and what is not yet ready. for example, the "if exists" clause, using when dropping a table seems not to be supported. Is any documentation available on the supported syntax, datatypes etc? Thanks, Regards, Dolf Smits Dolf Smits Senior Consultant Meta Directory Solutions Siemens Nederland N.V. Siemens Business Services Bezoekadres Prinses Beatrixlaan 26 Den Haag Correspondentieadres Postbus 16068 NL-2500 BB Den Haag 070 333 3654 070 333 2511 06 55844837 Dolf.Smits(a)siemens.com www.siemens.nl Deze e-mail is uitsluitend bedoeld voor kennisneming door de geadresseerde(n), en mag niet aan anderen worden doorgestuurd of op andere wijze ter kennis worden gebracht. Indien u niet de geadresseerde bent, verzoek ik u om de afzender te waarschuwen en de e-mail direct te verwijderen/vernietigen. De afzender wijst elke aansprakelijkheid voor (de inhoud van) deze e-mail af.

1 0

[MonetDB-users] questions regarding mil-sql interoperation and savepoint behavior
by Kinzer, Jason M (Jason) 26 Feb '05

26 Feb '05

Hi, I'm exploring Monet, and it's a very pleasant experience. I have a few questions however; please forgive the parade of ignorance that follows: - If one creates persistent void-head BATs via MIL, is there a way to them as columns of a SQL table/view. I noticed the parser had a rule allowing "CREATE VIEW ... AS BATS", but wasn't quite sure how to use it. - Conversely, if one has a set of tables, is there any easy way to find that mapping of columns to bat ids (e.g. so that one can lookup individual bats in MIL)? It appears this information is really only persisted in the log file, is that correct? If so, I assume the only other option would be to have the sql module loaded, and then access the temporary bats it creates that hold this metadata (I didn't notice that the module exported any MIL-accessible functions for grabbing the sql_column data)? - I am wondering how transaction chains are supposed to behave w.r.t. memory consumption. Specifically, I noticed that when executing "savepoint x" in the mapiclient, the heap size of the Monet process climbs almost monotonically upwards - jumping perhaps 350K per savepoint (every tx is completely empty) and hardly falling at all following releases or rollbacks (or even client disconnect for that matter). My understanding is that a savepoint is essentially a child transaction (thus copied from the parent), in which case I'm worried it may not be releasing all resources related to the tx and therefore leaking memory? Or is it simply that monet is allocating additional space from the OS, say for BATs related to the transaction, and this memory is becoming part of the internal pool and thus not being release back to the OS? I'd assume the second except that I thought it would reuse the space so that the heap size would stop climbing after a while, and I never did reach that poi! nt even after 100's of savepoints and an 30-fold increase in heap size. (BTW, I'm running the pre-build MonetDB 4.6.0/SQL 2.6.0 on Win2K). Many thanks for your time, and any responses. Cheers, Jason

1 0

[MonetDB-users] compile on Windows - pthread version
by Michael Schmid 24 Feb '05

24 Feb '05

Hello, i am a new user of MonetDB and want to share my problems and solutions with you. I try'ed to compile the source code version on Windows and run in a problem: the comiler give out an error: can not convert from pthread_t to int ...... After study some source code, and read the history of changes in the pthread distro, i read about changing this structure. I downloaded older versions of the Pthread lib, and finally: it compiles well. But only with pthreads-2004-06-22.exe or older, all newer version give the above error. From the Pthreads news "SNAPSHOT 2004-11-03 ------------------- DLLs produced from this snapshot cannot be used with older applications without recompiling the application, due to a change to pthread_t to provide unique POSIX thread IDs." i guess, this is the reason. You should make a hint in the HowToStart-Win32.txt to this, so that other users dont have the same problem. This problem occors on Win2000 and WinXP, with the the release and the CVS code. Do you have plans to change the code the new pthread_t structure, so that newer versions of the PThread distro can be used? Best regards, Michael Schmid

2 1

[MonetDB-users] Delete is slow?
by Edmund Dengler 14 Feb '05

14 Feb '05

Howdy! I'm taking some time to see what MonetDB is all about, and I have some questions re performance. I created 6 BATs (basically BAT[LNG, X] where X = INT, OID, TIMESTAMP, BLOB) to test. I loaded up about 250k rows (loading was quite reasonable, even though I was using the Perl interface to do it one row at a time). I am currently trying to delete the BUNs by doing a series of "bat("bat_name").delete();", and it is just taking forever (currently at over an hour!!). I/O is extremely minimal, CPU is nailed to 100% (this is running the latest release candidate off of sourceforge on a Linux 2.6 Gentoo system). Questions: Should delete be so slow? Is there a dependency between tables that is somehow forcing an N^2 or N^3 algorithm to run? Is there an equivalent to "truncate" other than destroy() and recreate? Regards! Ed

5 17

[MonetDB-users] ascii_io
by Edmund Dengler 11 Feb '05

11 Feb '05

Greetings! Looking at the ascii_io module, I can't seem to find a way for loading up multiple BATs where one column of the input is specified as the head value. Is there such an option, or is it always a VOID loadup? In particular, I have a << lng >> column as the primary key. So, using my current understanding, I would need to load up a set of dummy/temp BATs, and then using these load the data to the real BATs. Regards! Ed

3 5

[MonetDB-users] Design of bat layout
by Edmund Dengler 11 Feb '05

11 Feb '05

Greetings! I have a question concerning how to design the data structures for a particular problem. I have a set of records, each record may have 0 to 20 strings associated with it. If I was to use an SQL database, I would use a table such as: table strings ( long record_id, int index, string string ); I was thinking of using a BAT within a BAT, something like: BAT[ BAT[ lng, int ], str ] but this cannot be made persistent. Using: bat(lng, str).rename("string_1"); bat(lng, str).rename("string_2"); ... bat(lng, str).rename("string_20"); just feels wrong (if for no other reason, what if there is a 21st string in the future?). I could do: bat(lng::1, lng::2).rename("record_strings"); bat(lng::1, int).rename("record_string_index"); bat(lng::1, str).rename("record_string_string"); But this means I am essentially limiting my record IDs to not be the full rnage of a long. What would be the suggested structure to use in this case? Regards! Ed

1 0

[MonetDB-users] New release-candidates "MonetDB-4.6.0_rc0" & "MonetDB-SQL-2.6.0_rc0"
by Stefan.Manegold＠cwi.nl 21 Jan '05

21 Jan '05

[ Please accept my apologies for this "broadcast mail". ] [ Future announcements concerning MonetDB and its elated projects will only ] [ go to the monetdb-announce mailing list ] [ (http://lists.sourceforge.net/lists/listinfo/monetdb-announce), so please ] [ do not forget to subscribe there, in case you are not subscribed, yet. ] Dear MonetDB users and developers (and those who want to become either or both ;-), In preparation for the release of the new MonetDB-4.6.0 & MonetDB-SQL-2.6.0 (planned for February 14 2005, cf. http://monetdb.cwi.nl/Development/Roadmap/), I just prepared the respective release-candidate branches "MonetDB_4-6" & "SQL_2-6" in our CVS repository on SourceForge (http://sourceforge.net/cvs/?group_id=56967). The first release-candidate versions are tagged as "MonetDB_4-6-0_rc0" & "SQL_2-6-0_rc0", respectively. Pre-packaged source- & binary-distributions are not available, yet, but they will be made available for download with in a few days, and announced separately. All users are highly advised (actually "requested" ;-) to use the new release-candidate( branche)s as of now (see below for details concerning CVS checkout/update). Please do not hesitate to ask for support and report bugs or problems, preferably via the bug tracing system at SourceForge (http://sourceforge.net/tracker/?group_id=56967&atid=482468) or via email to monet(a)cwi.nl; however, please always state clearly, which version of MonetDB-SQL you are using (as the Mserver tells you at startup)! Any support for the now obsolete "MonetDB-4.4.x" & "MonetDB-SQL_2.4.x" will stop as of now. Contents: ========= - Background - Change Logs - CVS update - CVS check-ins - Testing Background ========== Trying to stick to our road-map (http://monetdb.cwi.nl/Development/Roadmap/), we plan the release of MonetDB-4.6.0 + MonetDB-SQL-2.6.0 for February 14 2004. As with earlier "pre-releases" of MonetDB & MonetDB-SQL, we start with "release-candidates" to allow testing by a larger group of users before we finally make the actual releases. Hence, starting to use the release-candidates as soon as possible will only be for your own benefit ;-) According to our TestWeb (http://monetdb.cwi.nl/Development/TestWeb/), both MonetDB and SQL are doing quite well right now; hence, I don't expect any (major) problems. Change Logs =========== Information about the major changes since MonetDB-4.4.2 / MonetDB-SQL_2.4.2 will follow with the pre-packaged source- & binary-distributions within a few days. CVS update ========== If you are already using the release branches "MonetDB_4-4-0" and "SQL_2-4-0" from CVS, simply run "cvs update -dP" to update your code to this new release candidate version. If you are already using a CVS version of MonetDB/MonetDB-SQL, you can run either "cvs update -dP -rMonetDB_4-6-0_rc0" "cvs update -dP -rSQL_2-6-0_rc0" to get this very release candidate, or "cvs update -dP -rMonetDB_4-6" "cvs update -dP -rSQL_2-6" to get the most recent version in the release candidate branch. The difference is, that via the first option, you are "stuck" with this very release candidate, i.e., future "cvs update -dP" (without "-r..." or "-A") will not change your checked-out version; via the second option, however, future "cvs update -dP" will get you again the latest version in the release candidate branch. CVS check-ins ============= All bug fixes (and only these!) on MonetDB and/or SQL are bound to go to the new release-candidate branches ("MonetDB_4-6"/"SQL_2-6"), only. On a regular basis, I will then take care of propagating these bug-fixes back to the respective main branch. All new features are bound to go to the main branches (and only there!). This release-candidate branch will become the new stable/release branch within the next 3 weeks. Testing ======= Nightly automatic testing will proceed "as usual". See http://monetdb.cwi.nl/Development/TestWeb/ for details. As usually, any (constructive;-) comments and feedback are more than welcome! Enjoy! Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[MonetDB-users] Bulk Load
by Sandy Ganz 04 Jan '05

04 Jan '05

Just started playing with MonetDB, and it is a tremendous piece of work. I do have a question on bulk loading table, i.e, a dump of some large tables we have in sybase for some testing. I found the ascii_io module and it looks like it is what is supposed to be used, if so is their and example of the format for the load_format() and any other helpfull tips. Looking at loading about 30 Million rows for some testing. Thanks for any help Sandy

1 0