- users-list - monetdb.org

Grant access to sql system catalog
by Suresh Devarakonda 29 Jun '20

29 Jun '20

Hi, I just wanted to check if there is a way to grant access to system tables and views such as sys.tables and sys.schemas to the users other than granting "sysadmin" role. I am not sure what kind of privileges the sysadmin role possess so would like to find if there are other roles or privileges available to access system tables and views. [cid:image001.jpg@01D64952.B2EE5CC0] Suresh Devarakonda 84.51<http://www.8451.com/>° TDO - Database Support Team D: 513.632.3692 M: 859.512.1839 A: 100 W. 5th Street, Cincinnati, Ohio 45202 Cincinnati | Chicago | New York | Portland Facebook<https://www.facebook.com/8451group/?ref=aymt_homepage_panel> LinkedIn<https://www.linkedin.com/company/84-51/?trk=biz-companies-cym> Instagram<https://www.instagram.com/84.51/> Twitter<https://twitter.com/8451group> Please consider the environment before printing this email.

2 1

Predicates in UDFs
by Oxana Dolmatova 25 Jun '20

25 Jun '20

Hello, Could you please explain why predicates with subqueries in UDFs do not work? For example, I have the following statements: create table itab (x int, y int); insert into itab values (1, 0); insert into itab values (2, 1); create function test1(n int) returns int begin while (n > 9) do set n = n -1; end while; return n; end; create function test2(n int) returns int begin while (n > (select 9 from itab) ) do set n = n -1; end while; return n; end; create function test3(n int) returns int begin while (exists (select x from itab where x < n)) do set n = n -1; end while; return n; end; The function test1 can be successfully created and executed, but functions test2 and test3 cannot be created and executed. Thank you and best regards, Oksana

2 3

Re: MonetDB Table Append
by Niels Nes 22 Jun '20

22 Jun '20

On Mon, Jun 22, 2020 at 08:11:26PM +0400, Miro Mannino wrote: > Dear Niels Nes, > > We would like to insert data column by column, for various reasons. > > The problem is that if we create a larger table with column T1 and > column T2, and insert 1000 rows on column T1, then the next 1000 insert > on T2 are going to be appended, resulting in 1000 rows of (val, NULL) > followed by another 1000 rows of (NULL, val). We could do that if there > is an option to INSERT INTO from the first row as well (ignoring > non-null values). > > In general, we are trying to use MonetDB taking advantage of a column > store DB, but we can't really insert a batch of values for one column > after another column due to the usual semantic of INSERT INTO that > works really in rows. > > Looking forward to hearing from you, Column by column inserts is indeed a problem with the sql language being row oriented. We do have some solution, ie binary copy into, but that maybe a bit too much for you. See https://www.monetdb.org/Documentation/Cookbooks/SQLrecipes/BinaryBulkLoad Niels > > Miro > > > > On Mon, Jun 22, 2020 at 8:02 PM Niels Nes <Niels.Nes(a)cwi.nl> wrote: > > Min > > Why don't you just create one larger table? > > Niels > > On 22 June 2020 14:59:44 CEST, Min Kyu Jung <mkj280(a)nyu.edu> wrote: > > To whom this may concern, > > I am Min, and I am currently utilizing MonetDB for a project > and I was wondering if there are any optimizations made in > MonetDB such that two tables with the same number of rows can > be joined together? > For example, consider the following two table: > CREATE TABLE t1(rowNumber, val); > WITH SERIES AS( SELECT * FROM generate_series(0, 10000)) > INSERT INTO t1 SELECT ROW_NUMBER() over (), rand() FROM series; > CREATE TABLE t2(rowNumber, val); > WITH SERIES AS( SELECT * FROM generate_series(0, 10000)) > INSERT INTO t2 SELECT ROW_NUMBER() over (), rand() FROM series; > > In this situation, I currently join the table as follows: > CREATE TABLE t3(row#, val1, val2); > INSERT INTO t3 SELECT ROW_NUMBER(), t1.val, t2.val FROM t1 > INNER JOIN t2 on t1.rowNumber = t2.rowNumber; > > Given that MonetDB is column-stored, I was wondering if there > is a simpler/faster/more optimized way of stitching the two > tables into one table. > > To be clearer, as of right now, I make sure all tables have the > rowNumber column. However, is there a way where I can join > multiple tables (all with the same number of rows) without > pre-generating rowNumber column for each table? > An example is this: > INSERT INTO t3 SELECT t1.val, t2.val FROM t1 INNER JOIN t2 on > row_number(t1) = row_number(t2); > > Sincerely, > Min > -- Niels Nes, CTO, MonetDB Solutions url: https://www.monetdbsolutions.com e-mail: Niels.Nes(a)monetdbsolutions.com

2 1

MonetDB Table Append
by Min Kyu Jung 22 Jun '20

22 Jun '20

To whom this may concern, I am Min, and I am currently utilizing MonetDB for a project and I was wondering if there are any optimizations made in MonetDB such that two tables with the same number of rows can be joined together? For example, consider the following two table: CREATE TABLE t1(rowNumber, val); WITH SERIES AS( SELECT * FROM generate_series(0, 10000)) INSERT INTO t1 SELECT ROW_NUMBER() over (), rand() FROM series; CREATE TABLE t2(rowNumber, val); WITH SERIES AS( SELECT * FROM generate_series(0, 10000)) INSERT INTO t2 SELECT ROW_NUMBER() over (), rand() FROM series; In this situation, I currently join the table as follows: CREATE TABLE t3(row#, val1, val2); INSERT INTO t3 SELECT ROW_NUMBER(), t1.val, t2.val FROM t1 INNER JOIN t2 on t1.rowNumber = t2.rowNumber; Given that MonetDB is column-stored, I was wondering if there is a simpler/faster/more optimized way of stitching the two tables into one table. To be clearer, as of right now, I make sure all tables have the rowNumber column. However, is there a way where I can join multiple tables (all with the same number of rows) without pre-generating rowNumber column for each table? An example is this: INSERT INTO t3 SELECT t1.val, t2.val FROM t1 INNER JOIN t2 on row_number(t1) = row_number(t2); Sincerely, Min

2 1

Announcement: New Jun2020 Feature release of MonetDB suite
by Sjoerd Mullender 03 Jun '20

03 Jun '20

The MonetDB team at MonetDB BV is pleased to announce the Jun2020 feature release of the MonetDB suite of programs. More information about MonetDB can be found on our website at <https://www.monetdb.org/>. For details on this release, please see the release notes at <https://www.monetdb.org/Downloads/ReleaseNotes>. As usual, the download location is <https://www.monetdb.org/downloads/>. Jun 2020 feature release (11.37.7) MonetDB5 Server * The mserver5 option --verbose (-v) was removed. A similar effect can be had by issuing the query CALL logging.setcomplevel('SQL_TRANS', 'INFO'); as the monetdb user. * The functions algebra.intersect, algebra.semijoin, and algebra.crossproduct have an extra argument, bool max_one, which indicates that there must be no more than one match in the join. * The example module opt_sql_append is not installed in the binary packages anymore. * Added mserver5 option (--dbtrace=<path>) in order to be able to specify the output file any produced traces. * Removed function bat.setKey(). * algebra.rangejoin now has two extra arguments: anti:bit and symmetric:bit. * Added session identifier, number of workers and memory claim to the sysmon queue. * The worker (number of threads), memory (in MB) and optimizer pipeline limits can now be set per user session basis. The query and session timeouts are now set in seconds. * With required privileges an user can set resource limits for a session. * There are now versions of group.(sub)group(done) that produce a single output containing just the groups. * algebra.join and algebra.leftjoin now have forms which return a single column. The column that is returned is the left column of the two column version. * The MAL profiler now assigns the SQL TRACE output to the client record thereby avoiding the interaction with other queries, but loosing insight of competing queries. The stethoscope should be used for that. SELinux Support * There was a problem with the MonetDB SELinux support on Fedora 32. That is fixed in this release. In order to do a proper upgrade of the package if you have already installed MonetDB-selinux on Fedora 32, you may need to uninstall (dnf remove) the old package and then install the new. Whole System * A new system to deal with debug output has been implemented. There is now an option --dbtrace to mserver5 that takes a file argument to which debug output is written. The default value is the file mdbtrace.log inside the database directory. This option can also be set through the monetdb program. * The home directory of the automatically created monetdb user was changed from /var/MonetDB to /var/lib/monetdb (RPM based systems only). This home directory is (currently) not used for anything, though. * Python 2 support has been removed. There is now only support for using Python 3. * Removed support for bam and sam files. * Added mserver5 option (--set raw_strings=true|false) and monetdb database property (raw_strings=yes|no) to control interpretation of strings. Merovingian * On Fedora and RHEL systems (not RHEL 6), if monetdbd runs under systemd, when the package is updated, monetdbd (and hence any mserver5 process it runs) is restarted. * Added dbtrace mserver5 option to the daemon in order to set mserver5's output directory for the produced traces. Client Package * The monetdb-client-tools (Debian/Ubuntu) and MonetDB-client-tools (Fedora/RH) containing the stethoscope, tachograph, and tomograph has been removed. A completely new version of stethoscope will be released to replace the old version. * Removed the possibility of using the MD5 checksum for authentication purposes. It was never actively used but was there as an option. Now the option has been removed. * Add port and host as fields in the .monetdb file. * Added 'sessionid' column to system function sys.queue(), so each query gets tagged with the current session identifier * Allow monetdb user to control session and query time out and selectively stopping a client sessions with a soft termination request. ODBC Driver * The NUMERIC and FLOAT types are now handled fully. Before only DECIMAL, FLOAT, and DOUBLE were handled fully. * Some bugs were fixed in the passing back and forth between application and server of values of type GUID (UUID). MonetDB Common * The functions BATintersect, BATsemijoin, and BATsubcross have an extra argument, bool max_one, which indicates that there must be no more than one match in the join. * The "unique" property on BATs was removed. The property indicated that all values in a BAT *had* to be distinct, but this was not actually used. * A new type of candidate list has been introduced. Candidate lists are used internally to specify which rows of a column participate in an operation. Before, candidate lists always contained a list of candidate row IDs. The new candidate list type specifies a list of row IDs that should NOT be considered (negative candidates). * The maximum number of BATs in the system has been increased for 64 bit architectures. * The hash tables used internally by the system now uses a technique based on Linear Hashing which allows them to grow gracefully. This means that hash tables aren't removed and recreated nearly as often anymore. This also meant that the hash table had to be split into two files, which means that after an upgrade the hash tables have to be recreated. * Implemented a version of BATproject, called BATproject2, with two "right" arguments which conceptually follow each other. * Removed MT_mmap and MT_munmap from the list of exported functions. Use GDKmmap and GDKmunmap with the same parameters instead. * Changed the interface of the atom "fix" and "unfix" functions. They now return a value of type gdk_return to indicate success/failure. * Removed the tunique property. The tunique property indicated that all values in the column had to be distinct. It was removed because it wasn't used. * BATrangeselect now has two extra arguments: anti and symmetric (both bool). SQL Frontend * Updating the value of a sequence now requires privilege on its own schema. * The sys.querylog_enable(threshold integer) now actually enables the querylog and uses a threshold in milliseconds. * Removed UNION JOIN statements. They were dropped by the SQL:2003 standard, plus MonetDB implementation was not fully compliant. * The OFFSET value in the COPY INTO query now counts uninterpreted newlines. Before it counted "unquoted record separators" which meant that if you had a single quote on a line that you want to skip, you could not use the feature. * Added support for FROM RANGE MINVALUE TO RANGE MAXVALUE and FROM RANGE MINVALUE TO RANGE MAXVALUE WITH NULL VALUES cases in partitioned tables by range (before they weren't). * Removed support for Python 2. Python 2 itself is no longer supported. Use Python 3 instead. Functions that were declared as LANGUAGE PYTHON2 or LANGUAGE PYTHON2_MAP are changed to LANGUAGE PYTHON and LANGUAGE PYTHON_MAP respectively (without changing the Python code). * Implemented 'covar_pop' and 'covar_samp' aggregate functions, as well as their window function counterparts. Implemented 'stddev_samp', 'stddev_pop', 'var_samp', 'var_pop', 'corr' and 'group_concat' window function correspondents. * Extended SQL catalog with CREATE WINDOW syntax for user-defined SQL:2003 window functions. At the moment, window functions must be defined on the backend engine, i.e. on this case MAL. In the current implementation, the backend code generation creates two additional columns of type lng with the start and end offsets for each row. * Added prepared_statements_args view, which details the arguments for the prepared statements created in the current session. * Added sys.prepared_statements view, which lists the available prepared statements in the current session. * Added deallocate statements with the syntax 'DEALLOCATE [PREPARE] { number | ALL }', to close an existing prepared statement or all, through the SQL layer. Previously this feature was available via MAPI exclusively with the "release" command. * Added support for raw strings using the syntax r'' or R''. This means that C-like escapes will remain uninterpreted within those strings. For instance SELECT r'\"' returns a string of length two. The user needs to escape single quotes by doubling them: SELECT r''''. * Implemented ROLLUP, CUBE and GROUPING SETS from SQL:1999. They define grouping subsets used with the GROUP BY clause in order to compute partial groupings. Also, the GROUPING aggregate was added. This aggregate is a bitmask identifying the grouping columns not present in the generated grouping row when used with the operators described above. * Updated user session procedures by adding the possibility to set properties based on a session identifier. Optimizer pipeline: sys.setoptimizer(int, string) Number of worker threads: sys.setworkerlimit(int, int) Memory limits (in MB): sys.setmemorylimit(int, int) Query timeout (in ms): sys.setquerytimeout(int, int) Session timeout (in ms): sys.setsessiontimeout(int, int) The first argument corresponds to the id of the session to modify, and these procedures are bound to the monetdb user exclusively. The versions of the mentioned procedures with just the second argument were added as well, where the changes are reflected in the current user session, and therefore every user can call them. * The procedures sys.settimeout(bigint), sys.settimeout(bigint,bigint) and sys.session(bigint) are now deprecated. Instead use sys.setquerytimeout and sys.setsessiontimeout mentioned above. * Added SQL procedure sys.hot_snapshot() which can be used to write a snapshot of the database to a tar file. For example, sys.hot_snapshot('/tmp/snapshot.tar'). If compression support is compiled in, snapshots can also be compressed ('/tmp/snapshot.tar.gz'). The tar file expands to a single directory with the same name as the database that was snapshotted. This directory can be passed directly as the --dbpath argument of mserver5 or it can be copied into an existing dbfarm and started from monetdbd. Bug Fixes * 6298: unexpectedly slow execution of SELECT length(fieldname) FROM tablename LIMIT 1 queries * 6401: Suspected memory leak in mserver5 when creating/dropping tables * 6687: Count distinct very slow and use too much the hard drive * 6723: columns aliases duplicates should not be allowed. automatic aliasing required. * 6731: Add system view to allow querying of available prepared statements and their parameters * 6732: Add SQL command to close a specific prepared statement * 6750: Executing a query on a non-existing column on a remote table crashes the remote server * 6785: function sys.isaURL(url) should have been declared as sys.isaURL(string) * 6808: reveal the alarm.sleep procedure in SQL * 6813: function not_uniques(bigint) returns error when called * 6818: usage of multiple column expressions in where-clause (f(a), f(b)) in (select a, b) causes assertion failure on mserver5 * 6821: Failed to start monetdb with embedded python * 6828: Server crashes when executing a window query with ordering by EXTRACT date * 6846: Global temporary table not accessible in other connections / sessions * 6847: A simple way of speeding up impscheck for dense canditers * 6850: Idle timestamp not set * 6851: json parser doesn't parse integers correctly * 6863: thash files not released upon drop table * 6864: (I)LIKE with multiple % doen't find matches

1 0

Crashed Database
by Ariel Abadi 20 May '20

20 May '20

Hi! I have deployed several MonetDB databases on different customers, the database is excellent haven't had that much problems, but I'm starting feeling that the database is becoming "fragile" Yesterday I have 2 crashes... Firstly, a database of 2.4TB of data... Monet crashed... and the only information I have received was: ERR cli_mx[28693]: #main thread:!ERROR: BBPcheckbats: file /opt/monetdb/cli_mx/cli_mx/bat/52/5236.tail too small (expected 137803304, actual 137166848) 2020-05-19 11:10:00 MSG cli_mx[28693]: !ERROR: BBPcheckbats: file /opt/monetdb/cli_mx/cli_mx/bat/52/5236.tail too small (expected 137803304, actual 137166848) 2020-05-19 11:08:11 ERR control[28629]: (local): failed to fork mserver: database 'cli_mx' has crashed after starting, manual intervention needed, check monetdbd's logfile (merovingian.log) for details Obviously that info Ive got it from merovingian.log.... so, which is the manual intervention needed... dont know! We run a backup all the nights (we rsync the database farm against backup server). Dont know the reason, but it seems that at moment of the backup, eventhought the database was working fine... The backup was done. So when I received the "crashed" notice.. I tried to recover from the backup.... but it seems the copy was already failing. So I had to start from zero... uploading all the information again. it was a very tought job, once I completed (at 1am in the morning), I stopped the db to do backup.... Again... the database has crashed!!!! never again started!!!! In this case the error was the following: 2020-05-19 23:57:52 MSG merovingian[2379]: sending process 2389 (database 'cli_mx') the TERM signal 2020-05-19 23:57:53 MSG merovingian[2379]: database 'cli_mx' has shut down 2020-05-19 23:57:53 MSG control[2379]: (local): stopped database 'cli_mx' 2020-05-19 23:57:54 MSG merovingian[2379]: database 'cli_mx' (2389) has exited with exit status 0 So the 3rd time, needed to upload the information again.. I have just finished!... Now, obviously I am scared to stop and start the db... and till this moment i dont have a backup of the farm directory. Can someone please help me to find the problem why the database has crashed? The only thing that I found on the /var/log/messages was the following (may be this may help to find the issue) May 19 23:03:49 mx-pve kernel: [4716718.867312] mserver5[19453]: segfault at 138 ip 00007fad7b66b1e9 sp 00007ffe648e5600 error 6 in lib_sql.so[7fad7b532000+1bc000] May 19 23:10:03 mx-monet kernel: [4717092.595561] mserver5[22348]: segfault at 138 ip 00007f07572d41e9 sp 00007ffd9f5aa950 error 6 in lib_sql.so[7f075719b000+1bc000] May 19 23:15:03 mx-monet kernel: [4717392.674941] mserver5[24044]: segfault at 138 ip 00007f4e7c0041e9 sp 00007ffeab6e8e90 error 6 in lib_sql.so[7f4e7becb000+1bc000] May 19 23:16:57 mx-monet kernel: [4717506.863046] mserver5[24675]: segfault at 138 ip 00007f8710d891e9 sp 00007ffc71a0e4a0 error 6 in lib_sql.so[7f8710c50000+1bc000] Do you have an idea what can I do ???! The version Im using is: v11.35.19 (Nov2019-SP3) on a Linux Centos 7. Ariel

1 0

ILIKE Operator. Bad function?
by Ariel Abadi 20 May '20

20 May '20

Hi! May be some can help me. We are using the ILIKE operator to filter data. When we use a couple of "%" at a certain point the db stops filtering correctly. We started with *ILIKE '%guate%' *it found 7 records, then we changed to *ILIKE '%guate%**com% *it found 1 record (which is ok)... finally we changed to *ILIKE '%guate%mo%**com%**' *and now it didn't find anything :'( Please see the attached examples... *A*) sql>SELECT DISTINCT nts_area_name FROM sb_rmsv.nts_nt_sum_report WHERE nts_area_name *ILIKE '%guate%'*; +---------------------------+ | nts_area_name | +===========================+ | Guatemala | | Guatemala-Mobile | | Guatemala-Mobile Comcel | | Guatemala-Mobile Movistar | | Guatemala-Mobile PCS | | Guatemala-Telgua | | Guatemala-Telefonica | +---------------------------+ *B*) sql>SELECT DISTINCT nts_area_name FROM sb_rmsv.nts_nt_sum_report WHERE nts_area_name *ILIKE '%guate%**com%;* +-------------------------+ | nts_area_name | +=========================+ | Guatemala-Mobile Comcel | +-------------------------+ *C*) sql>SELECT DISTINCT nts_area_name FROM sb_rmsv.nts_nt_sum_report WHERE nts_area_name *ILIKE '%guate%mo%**com%**'*; +---------------+ | nts_area_name | +===============+ +---------------+ 0 tuples

4 6

Auto-scaling MonetDB cluster on AWS?
by Pascal Heus 18 May '20

18 May '20

Has anyone configured an scalable MonetDB using Docker cluster on Amazon Web Services or other cloud environment? I'm looking into setting this up for one of our project around COBID-19 and essentially need to: - have my number of MonetDB instances to go up and down with user demand - use a load balancer to spread user queries across multiple instances I had in mind that all the instances would just point to a single dbfarm directory (all the user queries are read only), but is this an option or will cause problems (locks, caching, etc.)? Based on what I understand from Cluster Management (https://www.monetdb.org/Documentation/Cookbooks/SQLrecipes/ClusterManagement) or Lazy Replication (https://www.monetdb.org/Documentation/Cookbooks/SQLrecipes/WorkloadCaptureR…) I need to replicate the database for each instance, which is not really practical. This document seems to hint that using the "Replication Services" model would be an option, but then I end up with any copies of the same database, and this will require a significant amount of extra disk space (the transaction logs + one copy per instance). http://www.exanest.eu/pub/2016_RTPBD_Monetdb.pdf Any guidance, suggestion, example would be greatly appreciated. best *P

2 1

MonetDB Cluster size
by 逄振洲 11 May '20

11 May '20

i am very interested in using MonetDB as OLAP solution，But now I have a few questions。 1. MonetDB cluster the largest scale ? 2. any customer case study ?

1 0

Integer divided by integer never produces a real number
by Groot, Frank (Sociale Verzekeringsbank) 23 Apr '20

23 Apr '20

Hi, Can you tell me which of the following division outcomes is expected behaviour? --Division -- outcome select 10/3, -- 3 10/3.0, -- 3.333 10.0/3, -- 3.333 cast(10 as decimal(18,2))/3, -- 3.333 cast(10 as decimal(18,0))/3, -- 3 cast(10 as decimal(18,0))/3.0 -- 3.333 ; Personally, I would have expected all of the outcomes to be real numbers and not integers. Can you tell me if that is a realistic expectation? Kind regards, Frank Groot

3 4