- users-list - monetdb.org

Iterations in MonetDB
by Oxana Dolmatova 23 Feb '22

23 Feb '22

Hello MonetDB Team, I want to integrate iterations into MonetDB using the barrier symbols provided by MAL (here the variable list_of_updates is repeated body of the iteration and ex_cond is the exit condition): ======================================= res_body = stmt_list(sql->sa, list_of_updates); stmt *s_begin = stmt_begin(sql->sa); list_append(res_list, s_begin); list_append(res_list, ex_cond); stmt *s_check = stmt_check(sql->sa, ex_cond, s_begin); list_append(res_list, s_check); list_append(res_list, res_body); list_append(res_list, stmt_redo(sql->sa, s_check)); list_append(res_list, stmt_exit(sql->sa, s_begin)); return stmt_list(sql->sa, res_list); ======================================== Currently the implementation works, when the exit condition is true, but unfortunately never stops, if the exit condition is false (I assume that this happens due to non-updating computation of ex_cond). Could you please give the reference point in the documentation or code where I could look to check if my assumption is correct? Or point me to a proper mailing-list if this is the wrong one for such questions? :) Thank you and best regards, Oksana

1 0

Fwd: COPY SELECT INTO with problems on new version 11.43.5 (Jan2022)
by Ariel Abadi 16 Feb '22

16 Feb '22

Hi All! I'm resending to the new user list. BR Ariel ---------- Forwarded message --------- From: Ariel Abadi <aabadi(a)starbi.com> Date: Fri, Feb 4, 2022, 18:44 Subject: COPY SELECT INTO with problems on new version 11.43.5 (Jan2022) To: Communication channel for MonetDB users <users-list(a)monetdb.org> Hi All! We found a problem on the new version 11.43.5 (Jan2022). We have some processes that run the COPY SELECT INTO to "move" data from monetdb to other different databases. We are expecting to receive an "answer" from monetdb affected, when the export finishes, like in the example below that informes "3 affected rows" sql>COPY SELECT * FROM cars INTO '/tmp/cars_out.csv' USING DELIMITERS ',' , '\n' , '"';*3 affected rows* While we run the same query on the new server, mclient/monetdb is not returning anything like the image below. sql>COPY SELECT * FROM cars INTO '/tmp/cars_out.csv' USING DELIMITERS ',' , '\n' , '"'; sql> Does anybody have the same issue? Am i doing something wrong? Thks a lot in advance! Ariel

2 1

Announcement: New Jan2022-SP1 Bugfix release of MonetDB suite
by Sjoerd Mullender 14 Feb '22

14 Feb '22

The MonetDB team at MonetDB Solutions BV is pleased to announce the Jan2022-SP1 bugfix 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/documentation/admin-guide/release-notes/jan2022/>. As usual, the download location is <https://www.monetdb.org/downloads/>. ### SQL Frontend - [This feature was already released in Jan2022 (11.43), but the ChangeLog was missing] Added SQL procedures sys.vacuum(sname string, tname string, cname string), sys.vacuum(sname string, tname string, cname string, interval int), sys.stop_vacuum(sname string, tname string, cname string). These can be used to vacuum string columns. ### Bug Fixes - [7228](https://github.com/MonetDB/MonetDB/issues/7228): COMMIT: transaction is aborted because of concurrency conflicts, will ROLLBACK instead - [7230](https://github.com/MonetDB/MonetDB/issues/7230): Prepared statement of INSERT with SELECT fails when types difer - [7232](https://github.com/MonetDB/MonetDB/issues/7232): False conflicts when inserting in a not null field - [7237](https://github.com/MonetDB/MonetDB/issues/7237): SELECT with concurrent writes rarely returns corrupt data - [7238](https://github.com/MonetDB/MonetDB/issues/7238): query with system function: "index"(varchar, boolean) fails with GDK error or assertion failure. - [7241](https://github.com/MonetDB/MonetDB/issues/7241): Replacing a view by a query on the view itself crashes the server.

1 0

mailing list software updated
by Sjoerd Mullender 10 Feb '22

10 Feb '22

I have updated the mailing list software on monetdb.org from mailman2 to mailman3. This means that the old accounts for managing list subscriptions do not work anymore. In order to manage your subscription using a web interface, you will need to create a new account at https://www.monetdb.org/lists/. You can associate multiple email addresses to this account and manage all your subscriptions at monetdb.org using a single account, even if they use different email addresses. Unlike in mailman2, in mailman3 the passwords are not saved in plaintext, and therefore they cannot be sent as a monthly reminder. Mailing list archives have been converted to the new system as well. The old web addresses (https://mail.monetdb.org/, https://www.monetdb.org/mailman/ and https://www.monetdb.org/pipermail/) now all get redirected to the new interface. -- Sjoerd Mullender

1 0

None
by None 10 Feb '22

10 Feb '22

keeping the BAT open (I always use "bat("name").XXX", or keep a ref variable in a block. So, as far as I can tell, I should not have 7500 BATs open at once. Am I misunderstanding? Or is there some underlying component/module keeping the BATs open? Or is this just the amount of memory MonetDB will use? I do not have a BAT of BATs (as I was sure that this would cause problems, and from your description, will indeed). Thanks! Ed

1 0

None
by None 10 Feb '22

10 Feb '22

columns in a BAT (ie, BAT[OID, any]), is this just the first BUN? For update operations, does this mean that in the middle of inserting into a set of BATs, that as the BUN count is different, a concurrent query may not realize that the two BATs are synced? (this gets back to multiple client isolation for changes) Thanks for your time! Regards! Ed

1 0

None
by None 10 Feb '22

10 Feb '22

"This is implemented by storing a very large OID for each column. An update to the column destroys this OID."

1 0

None
by None 10 Feb '22

10 Feb '22

"For BAT-sets that contain exactly the same sets of OIDs, those OID-columns can be marked synced(). This information is then used to use positional lookup (the i-th element in BAT1 corresponds with the i-th in BAT2) and to turn semijoin- into very cheap copy-operations, etc." almost makes it sound as if you need synched() to actual test and set this bit. Is this true? How is the "syncedness" ensured when I have a BAT[OID, any], or determined?

1 0

New MonetDB JDBC driver v3.2 and JdbcClient released
by Martin van Dinther 03 Feb '22

03 Feb '22

The MonetDB team at MonetDB BV is pleased to announce a feature release of the MonetDB JDBC driver (monetdb-jdbc-3.2.jre8.jar) and JdbcClient CLI program (jdbcclient.jre8.jar). The new release adds the capability to use the SQL: COPY ... INTO ... ON CLIENT statements via Java from the client side. This allows users and programmers to use the much faster COPY statements to load large data sets into MonetDB from a local client side CSV file or stream. The JDBC MonetConnection API has been extended with methods to register and use Upload and Download Handlers to stream the data from the Java client application to the server and/or from the server to the Java client. See <https://www.monetdb.org/downloads/Java/onclient.txt> for details. The new functionality has also been added to the JdbcClient CLI program, so you can now also use COPY ... INTO ... ON CLIENT statements from this CLI program, provided you have started it with a --csvdir argument. The CSV data files may also be gzip compressed (file name ends with: .gz). Besides this new functionality we also improved both the JDBC driver and JdbcClient to work optimal with the new MonetDB Jan2022 server release. For a list of all changes please read: <https://www.monetdb.org/downloads/Java/ChangeLog>. We recommend all users of MonetDB JDBC driver and/or JdbcClient program to upgrade to this new release. Especially if you use the new MonetDB Jan2022 server release, you should use the new jar files. The download location is as usual: <https://www.monetdb.org/downloads/Java/>. For information and tips on using the MonetDB JDBC driver, read: <https://www.monetdb.org/downloads/Java/release.txt>. Reminder: as of release monetdb-jdbc-3.0.jre8.jar the MonetDB JDBC Driver class name has been changed to: org.monetdb.jdbc.MonetDriver It used to be nl.cwi.monetdb.jdbc.MonetDriver which is marked as deprecated. Please use the new driver class name asap in your configuration files/scripts and/or Java code. The old driver class name is currently still included in the jdbc jar file but only to ease the transition for existing deployments. The old driver class will be removed in a future release of the MonetDB JDBC driver.

1 0

Announcement: New Jan2022 Feature release of MonetDB suite
by Sjoerd Mullender 24 Jan '22

24 Jan '22

The MonetDB team at MonetDB BV is pleased to announce the Jan2022 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/>. ## Jan2022 Feature Release (11.43.5) ### - A couple of concurrency issues have been fixed. ### Windows Packaging - We now build Windows binaries using Visual Studio 2022. ### Client Package - A new output formatting mode was added to mclient. Use -fcsv-noquote to produce a CSV (comma-separated values) output where the quote characters have not been escapes. This can be useful when producing a single column string output that should be saved as is, e.g. when using the sys.dump_database() function. ### MonetDB Common - Implement string imprints (strimps for short) a pre-filter structure for strings in order to accelerate LIKE queries. If a strimp exists for a specific string column the strings are pre-filtered, rejecting strings that cannot possibly match, before the more expensive and accurate matching algorithms run. - On Windows, files and directories we create now get the attribute FILE_ATTIBUTE_NOT_CONTENT_INDEXED, meaning that they should not be indexed by indexing or search services. - Many (most) low level functions that could take a long time (such as BATjoin) can now be aborted with a timeout. When the function takes too long, the function will fail, and hence the whole SQL query will fail. - At some point in the past, string heaps were created where the hash value of the string was stored in the heap before the string. This hasn't been used in a long time. Now the code that could still read those old heaps has been removed. Bats that used the old format are converted automatically. - Some small interface changes to the atom functions: the atomPut function now returns (var_t) -1 on error instead of 0; the atomHeap function now returns success or failure as a gdk_return value. ### General - Reliance on the OpenSSL library has been removed. OpenSSL was used for the hash algorithms it contained (e.g. SHA512 and RIPEMD160) and for producing random numbers. The hash functions have been replaced by the original published functions, and random numbers are generated using system-specific random sources (i.e. not simply pseudo-random number generators). ### MonetDB5 Server - The storage cleanup in the 11.41.5 (Jul2021) release made the OLTP optimizer pipeline obsolete, thus it was removed. ### SQL Frontend - Add string imprints to the existing imprints index creation syntax. On string column "col" of a table "tbl" marked read only ("ALTER TABLE tbl SET READ ONLY") the user can create a string imprint using the syntax: "CREATE IMPRINTS INDEX index_name ON tbl(col);". - With the storage cleanup in the 11.41.5 (Jul2021) release, the ANALYZE statement was updated to accomodate those changes. The SAMPLE parameter is now ignored because ANALYZE generated statistics used by relational operators, are required to be precise. - In order to mitigate the I/O required to update the 'statistics' table, this table is no longer persisted. Alternately, it was changed into a computed view every time when queried. The 'stamp' and 'sample' fields were removed for the aforementioned reasons. The 'schema', 'table' and 'column' fields were added for convenience. - In previous versions there was no check that the INCREMENT BY value of a SEQUENCE was not zero. During the automatic upgrade of a database, INCREMENT BY values that are zero are set to one. - The method to compute the 'side_effect' effect property was changed for SQL functions defined in the backend engine (eg. ``CREATE FUNCTION ... EXTERNAL NAME "module"."function"''). It was changed from being computed by the SQL layer to the backend engine itself. As a consequence, the computed 'side_effect' value may be different, thus bringing incompatibilities. After an upgrade, if a 'side_effect' incompatibility arises, either the 'side_effect' value in the backend should be changed or the function should be re-created in SQL. - Removed deprecated system view sys.systemfunctions. It was marked as deprecated from release Apr2019 (11.33.3). Use query: select id as function_id from sys.functions where system; to get the same data as the old view. - Extended SQL system catalog with lookup table sys.fkey_actions and view sys.fkeys to provide user friendly querying of existing foreign keys and their ON UPDATE and ON DELETE referential action specifications. - Many improvements were done for REMOTE table plans. As a consequence, master or slave servers from this feature release are not compatible with older releases. - The view sys.ids has been changed to give more information about the objects in the system. In particular, there is an extra column added at the end that indicates whether the object is a system object. - The example modules opt_sql_append and udf are no longer loaded by default and no longer part of the binary release. If installed, they can be loaded using the --loadmodule option. - The built-in SQL functions to produce a dump that were added as a proof-of-concept in the previous release have been improved and are now usable. Use the query ``SELECT stmt FROM sys.dump_database(FALSE) ORDER BY o'' to produce a dump. The dump code built into mclient and msqldump is probably still more efficient, though. - The sys.epoch function has always been confusing. There are two versions, one with an INTEGER argument, and one with a BIGINT argument. The former accepted values as seconds, whereas the latter expected milliseconds. Also, the construct EXTRACT(EPOCH FROM value) returns a BIGINT with millisecond precision. This has now been overhauled. There is no longer a function sys.epoch with BIGINT argument, but instead there is a new function sys.epoch with DECIMAL(18,3) argument. The argument is seconds, but with 3 decimals, it provides millisecond accuracy. Also the EXTRACT(EPOCH FROM value) now returns a DECIMAL(18,3), again seconds with 3 decimals giving millisecond accuracy. Note that the internal, binary representation of DECIMAL(18,3) interpreted as seconds with 3 decimals and BIGINT with millisecond precision is exactly the same. ### Merovingian - Disabled logging into merovingian.log of next info message types: - proxying client <host>:<port> for database '<dbname>' to <url> - target connection is on local UNIX domain socket, passing on filedescriptor instead of proxying These messages were written to the log file at each connection. In most cases this information is not used. The disabling reduces the log file size. - Removed the deprecated monetdb commands `profilerstart` and `profilerstop`. ### Bug Fixes - [7168](https://github.com/MonetDB/MonetDB/issues/7168): Loosing the documentation - [7180](https://github.com/MonetDB/MonetDB/issues/7180): GROUP BY-subquery crashes MonetDb - [7182](https://github.com/MonetDB/MonetDB/issues/7182): Queries against sys.querylog_catalog, sys.querylog_calls or sys.querylog_history fail after restore of a db created using call sys.hot_snapshot(R'\path\file.tar'); - [7201](https://github.com/MonetDB/MonetDB/issues/7201): Selection of a subquery with a LEFT JOIN returns the wrong result set - [7202](https://github.com/MonetDB/MonetDB/issues/7202): DISTINCT does not work when sorting by additional columns - [7215](https://github.com/MonetDB/MonetDB/issues/7215): ODBC Driver SQLStatistics returns duplicate rows/rows for other tables

1 0