- users-list - monetdb.org

sub-second epoch precision
by Karl Seguin 17 Nov '20

17 Nov '20

I couldn't find a nice way to turn a timestamp into a sub-second epoch value. What I came up with was: sys.epoch(t) * 1000000 + cast((("second"(t) - floor("second"(t)))) * 1000000 as int) Most functions seem to treat seconds as the lowest unit, e.g. extract(seconds...) and time_to_str Is there a better option that I'm missing? Thanks, Karl

1 0

changes with temporal types
by Roberto Cornacchia 03 Nov '20

03 Nov '20

Hi team, I like the Oct2020 release very much. It has some discontinuities with past releases, and that's ok. One that I find a bit too painful though is the stricter time and interval typing. Not that I am against it, it is now more SQL compliant. But perhaps the transition could have been a bit softer. It boils down to date arithmetics between temporal and numeric types. Something like this was allowed before: 1 + (date1 - date2) (integer + interval) As the release notes say, a new function epoch_ms() has been added to help the transition. This function can turn dates and intervals into the number (int) of milliseconds since 1970-01-01 00:00:00 UTC. So if one really needs such arithmetics, could do something like 1 + epoch_ms(date1 - date2) The problem with this is that this function was not available in earlier releases. This makes the migration of existing applications very hard, because there is no combination that works in all cases: Deployed application Old MonetDB New MonetDB int + interval works fails int + cast(interval as int) works fails int + epoch_ms(interval) fails works As you see, there is no overlap between the solutions that worked with MonetDB < Oct2020 and those that work with MonetDB Oct2020. I wonder, would it have been such a bad idea to make the transition as it was done, but leave the ability to cast an interval to a number? At least for a couple of releases? We are now facing the issue that if we want to roll forward to MonetDB Oct2020, at the same time we need to make sure to redeploy our code to be compatible with it. There is so much that could go wrong with this! It's scary. I've nothing against breaking backward compatibility, but honestly I don't see the urgency in removing that cast, it would have helped a lot. Roberto Cornacchia +31 (0) 6 27 232 270 www.spinque.com

3 3

Github mirror
by Roberto Cornacchia 26 Oct '20

26 Oct '20

Hello, I was wondering, is the syncing of the github repository mirror not scheduled? I see that the latest commit on master is from today, but the latest commit on Oct2020 branch is from 14 days ago.

2 2

Announcement: New Oct2020 Feature release of MonetDB suite
by Sjoerd Mullender 19 Oct '20

19 Oct '20

The MonetDB team at MonetDB BV is pleased to announce the Oct2020 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/>. Oct 2020 feature release (11.39.5) MonetDB5 Server * The settings for specifying how mserver5 should listen to "The Internet" have been overhauled. See the manual for details. In brief, mapi_autosense, mapi_ipv6 and mapi_open are gone. If mapi_listenaddr equals "localhost" or "all", we listen to both IPv4 and IPv6 (if available), if "127.0.0.1" or "0.0.0.0", we listen to IPv4 only, if "::1" or "::" we listen to IPv6 only. The first of each pair is loopback interface only, the second is all interfaces. If mapi_listenaddr is "none", then no IP port is opened, you need to use a UNIX domain socket. If mapi_port is 0, we let the operating system choose a free port (like mapi_autosense). Default behavior has not changed. Whole System * Finished a first version of the new monitoring function user_statistics(), which is only intended for the DBAs. For each database user who has logged in during the current mserver5 session, it returns "username": login name of the database user, "querycount": the number of queries this user has executed since his/her first login, "totalticks": the total execution time (in microsecond) of the queries ran by this user, "maxquery": the query with the longest execution time (if two queries have the same execution time, the newer overwrites the older), "maxticks": the execution time of the 'maxquery' (in microsecond), "started": the start timestamp of the 'maxquery', "finished": the finish timestamp of the 'maxquery'. * Removed support for LiDAR data, that is the SQL procedures sys.lidarattach, sys.lidarload, and sys.lidarexport. * The sys.queue() has been turned into a circular buffer to allow for inspection of both active, paused and recently executed queries. Client Package * mclient and msqldump now also look in $XDG_CONFIG_HOME for the monetdb configuration file. SQL Frontend * Extended the system monitor with a table-returning function user_statistics() which keeps some statistics for each SQL user, e.g. the user's query count, total time spent, and maximal query seen. * Removed '@' syntax used to refer into a variable in a query. It was a non-standard method, which was replaced by a schema addition to variables. Variables in the global scope now have schema. All default global variables are set under schema "sys". However variables inside PSM don't have a schema, because there are no transaction semantics inside PSM at the moment. * Removed declared variables and tables from the global scope. They were transaction agnostic and incompatible with the SQL standard, i.e. they are valid exclusively under PSM (e.g. functions, procedures and triggers). * Scoping semantics were added for both variables and tables. Variables with the same name at a query are now resolved under the following precedence rules: 1. Tables, Views and CTEs at the FROM clause. 2. Variable declared in the body of function/procedure, i.e. local variable. 3. Function/procedure parameter. 4. Variable from the global scope. Tables with the same name now have the following precedence rules at a SQL query: 1. Table declared in the body of function/procedure, ie local table. 2. Temporary table. 3. Table from the current session schema. This means the query: SELECT * FROM "keys"; will list keys from temporary tables instead of persisted ones, because "keys" table is available for both "sys" and "tmp" schemas. * The table returning function "var" was extended with more details about globally declared variables, namely their schema, type and current value. * Removed obsolete sys.getContent(url) function. * Removed obsolete json.output(json) function. * Removed compatibility between interval types and other numeric types in favor for a more strict SQL standard compliance. This means operations between temporal types and other numeric types such as INT and DECIMAL are no longer possible, instead use interval types. e.g. SELECT date '2020-01-01' + 1; now gives the error. Instead do: SELECT date '2020-01-01' + interval '1' day; if 1 was meant to be a day interval. Setting an interval variable such as the session's current timezone with a number e.g. SET current_timezone = 1; is no longer possible. Instead do SET current_timezone = interval '1' hour; Casting between interval and other numeric types is no longer possible as well, because they are not compatible. * Because of incompatibilities this change may create, if a user intends to convert a numeric value to an interval, the multiplication function can be used in the form: <numeric value> * interval '1' <interval length> e.g. 10 * interval '1' second = interval '10' second. As for the other way around, the 'EPOCH' option was added to the extract syntax. This option returns the number of milliseconds since the UNIX epoch 1970-01-01 00:00:00 UTC for date, timestamp and time values (it can be negative). Meanwhile, for day and second intervals, it returns the total number of milliseconds in the interval. As a side note, the 'EPOCH' option is not available for month intervals, because this conversion is not transparent for this type. * Made general logarithm function log(x,base) compliant with the SQL standard, by swapping the input parameters. Instead of log(x,base), now is log(base,x). Bug Fixes * 3553: All schema access to ubiquitous functions * 3815: Incorrect results when expression contains implicit float/integer conversions * 6415: Date arithmetic types are inconsistent * 6814: provide native implementations for scalar functions sys.degrees(rad) and sys.radians(deg) * 6843: function sys.getcontent(url) always returns "Feature not supported" * 6857: remove not implemented aggregate function json.output(js json) * 6870: Missing bulk operators * 6878: SQL Connection Error when running SELECT queries containing AND command * 6910: SQLancer query: 'bat.append' undefined * 6930: SQLancer crash on join with coalesce * 6931: Allow EDITOR to be used for the current command in mclient * 6935: Wrong result when dividing interval by literal float * 6937: Lost the microsecond precisions * 6938: Segmentation fault in MalOptimizer * 6939: Error in optimizer multiplex when selecting profiler.getlimit() or wlc.clock() or wlc.tick() or wlr.clock() or wlr.tick() * 6941: SELECT queries on remote table fail when using LIKE in WHERE conditions * 6943: JSON parser is too permissive * 6948: msqldump with Empty BLOBs cannot be imported * 6949: Loosing timing precision * 6950: redundant/replicated code line in gdk/gdk_hash.c * 6951: Use a different naming scheme for MAL blocks * 6954: FILTER functions no longer find their implementation * 6955: ROUND(DECIMAL, PRECISION) gives incorrect result with non-scalar precision parameter * 6960: implementation of log(arg1,arg2) function is not compliant with the SQL standard, arguments are switched * 6962: "SELECT * FROM ids LIMIT 1" produces: exp_bin: !ERROR: Could not find %173.id * 6964: Table returning function: Cannot access column descriptor * 6965: Crash when using distinct on the result of a table returning function * 6974: Oct2020-branch cannot attach and load FITS files * 6976: Oct2020: default dbfarm cannot be started * 6978: Oct2020: \d shows empty result in schema created by include sql script * 6979: timestamp add integer * 6980: Oct2020: wrong mel definition for str.epilogue

1 0

Thread safety in python UDFs
by Ioannis Foufoulas 01 Oct '20

01 Oct '20

Hi, One question on python udfs. What about thread safety? In case of concurrent execution of numpy UDFs should the UDF developer use thread-safe structures or Monetdb handles this in some way? For example, pandas is not thread safe. This means that it should not be used in a UDF? Best, Yannis

2 1

Building MonetDBe from source
by Avik Sengupta 24 Sep '20

24 Sep '20

Hi, I've been trying to build MoneDBe from source, using Github master. I do not want to build the full executables, so I have used cmake --build . --target monetdbe With this, I am able to successfully build libmonetdbe.so. So that is great. However there does not seem to be an install-monetdbe or similar target. Running the `install` target tries to compile the whole application, which is not what I want. How do I copy the compiled artifacts (libmonetdbe.so and dependencies) to my install prefix? I'm trying not to have to manually copy the libraries. Regards - Avik

1 0

.mal and .sql files in Oct2020 lib folder
by Roberto Cornacchia 24 Sep '20

24 Sep '20

Hi there, I'm trying to compile from the Oct2020 branch and I have a question about the /lib64/monetdb5 folder. This folder used to contain .mal files. It also contained an autoload/ subfolder and a createdb/ subfolder (with .sql files). I don't see the same in the Oct2020 installation. I see that the content of /sql/scripts/CMakeLists.txt is entirely commented out. Is the installation of all these files temporarily disabled during development, or is this handled differently now? Roberto

4 4

Re: Internals of intermediate results in MonetDB
by Guodong Jin 24 Sep '20

24 Sep '20

Thanks! The point to MAL plan really helps me out! Best, Guodong On Sep 21, 2020, 06:00 -0400, users-list-request(a)monetdb.org, wrote: > Send users-list mailing list submissions to > users-list(a)monetdb.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.monetdb.org/mailman/listinfo/users-list > or, via email, send a message with subject or body 'help' to > users-list-request(a)monetdb.org > > You can reach the person managing the list at > users-list-owner(a)monetdb.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of users-list digest..." > > > Today's Topics: > > 1. Internals of intermediate results in MonetDB (Guodong Jin) > 2. Re: Internals of intermediate results in MonetDB (Martin Kersten) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 20 Sep 2020 23:31:50 -0400 > From: Guodong Jin <guod.jin(a)gmail.com> > To: users-list(a)monetdb.org > Subject: Internals of intermediate results in MonetDB > Message-ID: <932d01d5-a742-4f57-8e19-ba7599667e42@Spark> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > Thanks for your hard works on this great open source project. > I?m a student newly working on MonetDB to implement some research ideas, and I want to understand internals of how MonetDB chooses to materialize and how it represents intermediate results. > As I understand, table data and intermediate results in MonetDB are all stored as BATs, but I?m not sure if there are some special optimizations on BATs, rather than just array(s) of atoms. Here are two simple examples to elaborate my questions a little bit: > > ?? ?1.Given two tables,?Items(id, order, price, tax), and?Orders(id, discount). > ?? ? ? ? ?Items > ?? ? ? ? ? ? ? ? ?[I1, I2, I3, I4, I5, I6, I7, I8, I9, I10, I11...] > ?? ? ? ? ? ? ? ? ?[O3, O3, O3, O3, O3, O3, O3, O3, O3, O3, O4...] > ?? ? ? ? ? ? ? ? ?[10, 11, 20, 15, 110, 80, 90, 12, 13, 88, 30...] > ?? ? ? ? ? ? ? ? ?[0.1, 0.15, 0, 0.1, 0.1, 0.15, 0.11, 0.18, 0.10, 0.15, 0.20, ...] > ?? ? ? ? ?Orders > ?? ? ? ? ? ? ? ? ?[O1, O2, O3] > ?? ? ? ? ? ? ? ? ?[0.8, 0.9, 0.95] > > ?? ? ? ? ?When we perform a join between these two tables on the field `order` (one-to-many relationship represented by the primary-foreign key, O3 matches with [I1, I2, ?, I10]),?in the output intermediate BATs of the join, will MonetDB duplicate `O3` 10 times? Are there any optimizations currently in MonetDB to remove/reduce the duplication? > > ?? ?2. Given a table?item(id, price, tax), when MonetDB performs the filter `price<10` on the table,?will MonetDB actually copy all matched tuples into intermediate BATs? Or just keep a list of OIDs of matched tuples as references? > > Thanks! > > Best, > Guodong >

1 0

Internals of intermediate results in MonetDB
by Guodong Jin 21 Sep '20

21 Sep '20

Hi all, Thanks for your hard works on this great open source project. I’m a student newly working on MonetDB to implement some research ideas, and I want to understand internals of how MonetDB chooses to materialize and how it represents intermediate results. As I understand, table data and intermediate results in MonetDB are all stored as BATs, but I’m not sure if there are some special optimizations on BATs, rather than just array(s) of atoms. Here are two simple examples to elaborate my questions a little bit: 1.Given two tables, Items(id, order, price, tax), and Orders(id, discount). Items [I1, I2, I3, I4, I5, I6, I7, I8, I9, I10, I11...] [O3, O3, O3, O3, O3, O3, O3, O3, O3, O3, O4...] [10, 11, 20, 15, 110, 80, 90, 12, 13, 88, 30...] [0.1, 0.15, 0, 0.1, 0.1, 0.15, 0.11, 0.18, 0.10, 0.15, 0.20, ...] Orders [O1, O2, O3] [0.8, 0.9, 0.95] When we perform a join between these two tables on the field `order` (one-to-many relationship represented by the primary-foreign key, O3 matches with [I1, I2, …, I10]), in the output intermediate BATs of the join, will MonetDB duplicate `O3` 10 times? Are there any optimizations currently in MonetDB to remove/reduce the duplication? 2. Given a table item(id, price, tax), when MonetDB performs the filter `price<10` on the table, will MonetDB actually copy all matched tuples into intermediate BATs? Or just keep a list of OIDs of matched tuples as references? Thanks! Best, Guodong

2 1

Merge table error with one table
by Ioannis Foufoulas 17 Sep '20

17 Sep '20

Hi, we encounter an error when only one table is added to a merge table definition During a query like "select * from merge table” we get: “Table: missing ')'" Probably merge tables cannot contain just one table but the returned error looks like a syntax error. Some more info to reproduce: the table that has been added to the merge table is a remote table. Best, Yannis

3 4