- developers-list - monetdb.org

Re: developers-list Digest, Vol 76, Issue 1
by Odin Loch 20 Jun '19

20 Jun '19

Where?! Need more details.. ________________________________ From: developers-list <developers-list-bounces+odin.loch=outlook.com.au(a)monetdb.org> on behalf of developers-list-request(a)monetdb.org <developers-list-request(a)monetdb.org> Sent: Thursday, June 20, 2019 8:00:02 PM To: developers-list(a)monetdb.org Subject: developers-list Digest, Vol 76, Issue 1 Send developers-list mailing list submissions to developers-list(a)monetdb.org To subscribe or unsubscribe via the World Wide Web, visit https://www.monetdb.org/mailman/listinfo/developers-list or, via email, send a message with subject or body 'help' to developers-list-request(a)monetdb.org You can reach the person managing the list at developers-list-owner(a)monetdb.org When replying, please edit your Subject line so it is more specific than "Re: Contents of developers-list digest..." Today's Topics: 1. UTF-8 data: copy into fails (Arjen P. de Vries) 2. Re: UTF-8 data: copy into fails (Panagiotis Koutsourakis) 3. Re: UTF-8 data: copy into fails (Arjen P. de Vries) ---------------------------------------------------------------------- Message: 1 Date: Wed, 19 Jun 2019 23:06:48 +0200 From: "Arjen P. de Vries" <arjen(a)acm.org> To: developers-list(a)monetdb.org Subject: UTF-8 data: copy into fails Message-ID: <CAM_um4c2Qyab7Y9E9efQqdgfGPBmSr7bns=49t+-goGCqiyNZw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I filed a bug report but did not see any response so maybe better mention it here: https://www.monetdb.org/bugzilla/show_bug.cgi?id=6716 Definitely would be nice to know if you can reproduce the bug as reported. Groetjes, Arjen _____ Please excuse brevity - sent from a mobile.

1 0

UTF-8 data: copy into fails
by Arjen P. de Vries 20 Jun '19

20 Jun '19

I filed a bug report but did not see any response so maybe better mention it here: https://www.monetdb.org/bugzilla/show_bug.cgi?id=6716 Definitely would be nice to know if you can reproduce the bug as reported. Groetjes, Arjen _____ Please excuse brevity - sent from a mobile.

3 2

Re: MonetDB: default - rewrite pairs of x >(=) lb and x <(=) hb into...
by Martin Kersten 27 Apr '19

27 Apr '19

:) On 27/04/2019 14:53, Niels Nes wrote: > Changeset: b9a037bfe7db for MonetDB > URL: https://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=b9a037bfe7db > Added Files: > sql/test/BugTracker-2019/Tests/duplicates-not-eliminated-long-CASE-stmt.Bug-6697.stable.out > Modified Files: > sql/common/sql_types.c > sql/server/rel_optimizer.c > sql/test/Tests/systemfunctions.stable.out > sql/test/Tests/systemfunctions.stable.out.int128 > Branch: default > Log Message: > > rewrite pairs of x >(=) lb and x <(=) hb into between calls

1 0

"ALTER TABLE name SET SCHEMA new_schema" support
by Anton Kravchenko 17 Apr '19

17 Apr '19

Is a table moving between schemas going to be supported in the next feature release? Thanks, Anton

2 1

Possible bug in pcre.c
by Roberto Cornacchia 08 Apr '19

08 Apr '19

Hi, I was looking at this piece of code (end of pcrejoin loop), and I have the feeling something isn't right. Inside the body of if (nl == 0) a condition over lastl is checked. However, it seems to me that lastl gets a useful value only when nl > 0. If (nl == 0) then lastl must be 0. <loop> { /* actual body */ .... /* track result properties */ if (BATcount(r1) > 0) { if (lastl + 1 != lo) r1->tseqbase = oid_nil; if (nl == 0) { r2->trevsorted = 0; if (lastl > lo) { r1->tsorted = 0; r1->tkey = 0; } else if (lastl < lo) { r1->trevsorted = 0; } else { r1->tkey = 0; } } } APPEND(r1, lo); APPEND(r2, ro); lastl = lo; nl++; }

2 2

Compiler optimizations and MonetDB performance
by aris 28 Mar '19

28 Mar '19

Hi all, One of our customers has pointed out that GCC 7+ has a reasonable large number of additions to their optimization algorithms and this customer was wondering if the MonetDB R&D community is aware of these compiler improvements and what their combined effect is on the performance of MonetDB. This customer seems to be contemplating to adopt the build process of MonetDB into their own build & deployment pipelines. So they are interested in the most optimal build signature for MonetDB on their Centos environment. Somebody already pointed out that given the kernel architecture of MonetDB, there is a chance that for instance, (new) inner loop optimizations can be useful for MonetDB since we put quite some effort into deciding which specialized algorithm to use for a particular relational algebraic operation before we dispatch the workload to the designated tight and specialized inner loop that does the actual work. Is anybody aware of existing evaluations/benchmarks related to different compiler, compiler settings and architectures/instruction set extensions? Or is it planned? Or should it be planned :) Kind regards, Aris

2 1

Re: MonetDB: subquery - return single column on in queries (with one...
by Martin Kersten 17 Mar '19

17 Mar '19

making progres ;) > On 17 Mar 2019, at 11:58, Niels Nes <commits+niels=cwi.nl(a)monetdb.org> wrote: > > Changeset: 4ca5e0d20906 for MonetDB > URL: https://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=4ca5e0d20906 > Modified Files: > sql/server/rel_select.c > sql/server/rel_unnest.c > sql/test/BugTracker-2014/Tests/in_incorrect_multi.Bug-3462.stable.err > Branch: subquery > Log Message: > > return single column on in queries (with one column on the left) > > > diffs (127 lines): > > diff --git a/sql/server/rel_select.c b/sql/server/rel_select.c > --- a/sql/server/rel_select.c > +++ b/sql/server/rel_select.c > @@ -1832,7 +1832,7 @@ rel_compare(sql_query *query, sql_rel *r > } else { > /* first try without current relation, too see if there > are correlations with the outer relation */ > - sql_rel *r = rel_subquery(query, NULL, ro, ek, 0);//APPLY_JOIN); > + sql_rel *r = rel_subquery(query, NULL, ro, ek, 0); > > /* NOT handled filter case */ > if (ro2) > @@ -1842,7 +1842,7 @@ rel_compare(sql_query *query, sql_rel *r > sql->session->status = 0; > sql->errstr[0] = 0; > query_push_outer(query, rel); > - r = rel_subquery(query, NULL, ro, ek, 0);// is_sql_sel(f)?APPLY_LOJ:APPLY_JOIN); > + r = rel_subquery(query, NULL, ro, ek, 0); > query_pop_outer(query); > > /* get inner queries result value, ie > @@ -2137,7 +2137,7 @@ rel_logical_value_exp(sql_query *query, > } else { > /* first try without current relation, too see if there > are correlations with the outer relation */ > - sql_rel *r = rel_subquery(query, NULL, ro, ek, 0);//APPLY_JOIN); > + sql_rel *r = rel_subquery(query, NULL, ro, ek, 0); > sql_exp *rs2 = NULL; > > /* correlation, ie return new relation */ > @@ -2147,8 +2147,10 @@ rel_logical_value_exp(sql_query *query, > /* reset error */ > sql->session->status = 0; > sql->errstr[0] = 0; > - if (!r) > + if (!r) { > + assert(0); > r = rel_subquery(query, *rel, ro, ek, is_sql_sel(f)?APPLY_LOJ:APPLY_JOIN); > + } > > /* get inner queries result value, ie > get last expression of r */ > @@ -2477,7 +2479,7 @@ rel_logical_value_exp(sql_query *query, > if ((!orel || (is_project(orel->op) && !is_processed(orel) && !orel->l && list_empty(orel->exps))) && !query_has_outer(query)) > orel = *rel = rel_project_exp(sql->sa, exp_atom_bool(sql->sa, 1)); > > - ek.card = card_set; > + ek.card = card_column; > if (is_sql_sel(f) && orel && is_project(orel->op) && !is_processed(orel)) { > needproj = 1; > pexps = orel->exps; > @@ -2811,13 +2813,13 @@ rel_logical_exp(sql_query *query, sql_re > if (!rel) > return NULL; > } > + return rel; > /* > rel = rel_logical_exp(query, rel, lo, f); > if (!rel) > return NULL; > return rel_logical_exp(query, rel, ro, f); > */ > - return rel; > } > case SQL_FILTER: > /* [ x,..] filter [ y,..] */ > @@ -2922,6 +2924,8 @@ rel_logical_exp(sql_query *query, sql_re > } > > } > + if (list_length(ll) > 1) > + ek.card = card_relation; > > /* list of values or subqueries */ > if (n->type == type_list) { > @@ -3021,7 +3025,7 @@ rel_logical_exp(sql_query *query, sql_re > } > if (l_used) > rel_join_add_exp(sql->sa, left, e); > - else if (!is_select(left->op)) > + else if (!is_select(left->op) || rel_is_ref(left)) > left = rel_select(sql->sa, left, e); > else > rel_select_add_exp(sql->sa, left, e); > @@ -3100,7 +3104,7 @@ rel_logical_exp(sql_query *query, sql_re > list *pexps = NULL; > int needproj = 0, exists=(sc->token == SQL_EXISTS); > > - ek.card = card_set; > + ek.card = card_column; > if (orel && is_project(orel->op) && !is_processed(orel)) { > needproj = 1; > pexps = orel->exps; > @@ -5777,7 +5781,7 @@ rel_value_exp2(sql_query *query, sql_rel > if (r) { > sql_exp *e; > > - if (ek.card <= card_column && is_project(r->op) && list_length(r->exps) > 1) > + if (ek.card <= card_set && is_project(r->op) && list_length(r->exps) > 1) > return sql_error(sql, 02, SQLSTATE(42000) "SELECT: subquery must return only one column"); > e = _rel_lastexp(sql, r); > > diff --git a/sql/server/rel_unnest.c b/sql/server/rel_unnest.c > --- a/sql/server/rel_unnest.c > +++ b/sql/server/rel_unnest.c > @@ -679,6 +679,9 @@ rel_unnest_dependent(mvc *sql, sql_rel * > return rel_unnest_dependent(sql, rel); > } > > + if (r && is_base(r->op)) /* table functions need dependent implementation */ > + return rel; > + > /* fallback */ > if ((ad = rel_dependent_var(sql, rel->l, rel->r)) != NULL) > rel = rel_general_unnest(sql, rel, ad); > diff --git a/sql/test/BugTracker-2014/Tests/in_incorrect_multi.Bug-3462.stable.err b/sql/test/BugTracker-2014/Tests/in_incorrect_multi.Bug-3462.stable.err > --- a/sql/test/BugTracker-2014/Tests/in_incorrect_multi.Bug-3462.stable.err > +++ b/sql/test/BugTracker-2014/Tests/in_incorrect_multi.Bug-3462.stable.err > @@ -31,7 +31,7 @@ stderr of test 'in_incorrect_multi.Bug-3 > MAPI = (monetdb) /var/tmp/mtest-27483/.s.monetdb.35395 > QUERY = SELECT * FROM SYS.ARGS > WHERE FUNC_ID NOT IN (SELECT * FROM SYS.FUNCTIONS); > -ERROR = !IN: inner query should return a single column > +ERROR = !SELECT: subquery must return only one column > CODE = 42000 > > > _______________________________________________ > checkin-list mailing list > checkin-list(a)monetdb.org > https://www.monetdb.org/mailman/listinfo/checkin-list

2 1

New Apr2019 stable branch created
by Sjoerd Mullender 18 Jan '19

18 Jan '19

I have created a new stable branch for the next feature release. This branch was created in order to stabilize the code before the feature release. From now on *only* bug fixes may go to this new stable branch. I reserve the right to undo any changes that do not comply with this rule. I also reserve the right to admit changes that are not strictly bug fixes. The name for the branch is Apr2019. So in each of your stable checkout directories you can do hg pull hg update -rApr2019 to update to this new branch. -- Sjoerd Mullender

1 0

Announcement: New Aug2018-SP2 Bugfix release of MonetDB suite
by Sjoerd Mullender 14 Jan '19

14 Jan '19

The MonetDB team at CWI/MonetDB BV is pleased to announce the Aug2018-SP2 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/Downloads/ReleaseNotes>. As usual, the download location is <https://dev.monetdb.org/downloads/>. Aug 2018-SP2 bugfix release (11.31.13) SQL Frontend * Disabled function sys.getcontent(url). Bug Fixes * 6643: schema name qualifier in create global temporary table json.table6643 ... is not honered * 6645: optimizer treats all the functions with no or constant parameters as constant * 6650: PREPARE SQL statement fails to compile user defined functions with parameter/s * 6651: Multi-column IN clause for subquery produces wrong results * 6653: CREATE TABLE accepts empty table/column name * 6654: Incorrect handling of 'TRUE' in compound select * 6657: Restart sequence with a non atomic sub-query cardinality gives wrong error message * 6660: GRANTing a ROLE is not idempotent * 6662: Concurrency Conflicts Exception string "!transaction is aborted because of concurrency conflicts, will ROLLBACK instead" not shown on prompt. * 6664: mserver5 crash: infinite recursive happens at rel_bin.c:489 * 6665: Creation of serial types does not accept negative numbers * 6666: COPY INTO from .. LOCKED doubles input data * 6668: The SAMPLE key word doesn't work in a subquery. * 6669: COPY [xxx RECORDS] INTO foo FROM STDIN ... doesn't work without specifying nr of to be copied records * 6672: SQLGetData with SQL_C_WCHAR string truncation and invalid StrLen_or_Ind value

1 0

How to perform copy into in multiple clients at the same time?
by Yinjie Lin 02 Jan '19

02 Jan '19

Hi, I'm new to MonetDB and I think this is a great project! I have a problem the same as this one: https://stackoverflow.com/questions/9179265/how-would-monetdb-perform-with-… , namely copy data into tables from multiple clients at the same time. As the stackoverflow question suggests, MonetDB uses Optimistic Concurrency Control, but the behaviour is different from my expectation. For example, say I have a table `t` without any constraints, and I run the following queries: client1 client2 ------------------------------------------------------------------- start transaction; insert into t values (1); start transaction; insert into t values (2); commit; commit; I would expect both commits succeed since the rows to be inserted do not conflict with each other and do not change original rows in the table. And this is the behaviour of some databases with OCC, e.g. TiDB (a MySQL compatible database). But MonetDB would rollback the second transaction. So my question is: is it possible to change this behaviour by modifying the code? If so, could you give me some guidance or suggestion? Thanks in advance! Best Regards, Yinjie Lin

4 5