Hi Sjoerd, The one problem that could occur is people trying to check out MonetDB_4-24 now, compiling it and trying to use with a precompiled MonetDB_1-24, without updating/recompiling that one. So, I agree with you that a problem could occur, but I would be surprised if any of our users would really hit this. With excuses to pick nits, but contrary to you I believe that API appends are not "just as bad" as API modifications. An API modification in MonetDB, would force a release in MonetDB5, for instance. An API append does not do that (so it is "less bad"). PF_ROX is quite different from the HEAD in the pathfinder code due to bot branches making different changes to the indexing scheme; afaik this has prevented us from keeping it in sync with the HEAD. Various API changes (not appends) and even buildtool changes now force it to depend on the stable MonetDB/MonetDB4. For PF_ROX itself this is not a problem as it has no outside users. However, it might occur that this scenario will repeat (PF_ROX triggering a change/addition in MonetDB/MonetDB4 that would trickle towards the head via MonetDB_[14]-24). Peter -----Original Message----- From: Sjoerd Mullender [mailto:sjoerd@acm.org] Sent: Tuesday, October 28, 2008 9:50 PM To: monetdb-developers@lists.sourceforge.net Cc: monetdb-checkins@lists.sourceforge.net Subject: Re: [Monetdb-checkins] MonetDB4/src/modules/contrib malalgebra.mx, MonetDB_4-24, 1.8.2.1, 1.8.2.2 On 2008-10-28 20:20, Peter Boncz wrote:
Hi Sjoerd,
Thanks for keeping an eye on developer behavior and effort to educate. My change, however, only introduces new functions in GDK and commands in MIL; it is only an API append.
API appends are just as bad as any other API change. If new code depends on the extra calls, it cannot run with the older version of the release. That is bad. It means that the branch is *not* "stable" anymore.
It is checked into the stable branch because afaik PF_ROX only works with that. But I may as often be mistaken.
Peter
This type of change is not allowed on a stable branch. Changes of API are *not* allowed.
Since we're going to abandon this stable branch soon, I'll let it pass.
On 2008-10-28 18:49, Peter Boncz wrote:
Update of /cvsroot/monetdb/MonetDB4/src/modules/contrib In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv901/src/modules/contrib
Modified Files: Tag: MonetDB_4-24 malalgebra.mx Log Message: changes to minimize sampling overhead (mostly in XML text index)
- introduce bandmergejoin(), and leftmergejoin()/bandmergejoin() with a cutoff
U malalgebra.mx Index: malalgebra.mx =================================================================== RCS file: /cvsroot/monetdb/MonetDB4/src/modules/contrib/malalgebra.mx,v retrieving revision 1.8.2.1 retrieving revision 1.8.2.2 diff -u -d -r1.8.2.1 -r1.8.2.2 --- malalgebra.mx 10 Oct 2008 08:42:22 -0000 1.8.2.1 +++ malalgebra.mx 28 Oct 2008 17:49:34 -0000 1.8.2.2 @@ -43,7 +43,6 @@ @:leftjoin(fetch,\nCAUTION: positional matches are assumed not to be out-of-bounds!!)@ @:leftjoin(merge)@ @:leftjoin(hash)@ - .COMMAND leftthetajoin ( BAT[any::1,any::2] left, BAT[any::2,any::3] right, int mode) : BAT[any::1,any::3] = CMDleftthetajoin; "Hook directly into the 'leftthetajoin' implementation of the join. @@ -58,6 +57,22 @@ Also, for each left tuple, all matching right tuples will appear in their order of appearrance in the right BAT. This property is handy for XQuery processing."
+ .COMMAND bandmergejoin ( BAT[any::1,any::2] outer, BAT[any::2,any::3] inner, + any::2 minus, any::2 plus, bit l_in, bit h_in) : + BAT[any::1,any::3] = CMDbandmergejoin; + "The bandjoin algorithm, but forced to use (left) mergejoin rather
nested loop" + + .COMMAND bandmergejoin ( BAT[any::1,any::2] outer, BAT[any::2,any::3] inner, + any::2 minus, any::2 plus, bit l_in, bit h_in, lng limit) : + BAT[lng,BAT] = CMDbandmergejoin_limit; + "A bandjoin that uses the merge algorithm and limits the result size. + Result generation is cut off after this point and the + result [lng,BAT] holds [estimated_full_resultsize,limited_result]" + + .COMMAND leftmergejoin ( BAT[any::1,any::2] left, BAT[any::2,any::3] right, lng limit) : + BAT[lng,BAT] = CMDleftmergejoin_limit; + "leftmergejoin, but limit the result (by cutting off result generation) + return a BAT[lng,BAT] containing [full_result_estimate,limited_result]"
@= select .COMMAND ord_@1select ( BAT[any::1,any::2] b, any::2 low, any::2 high) : @@ -119,6 +134,7 @@ #ifndef __MALALGEBRA_H__ #define __MALALGEBRA_H__ #include "gdk.h" +#include "gdk_rangejoin.h"
/* nothing much */
@@ -240,6 +256,40 @@ return (*result = BATnlthetajoin(l, r, *mode, (size_t) * estimate)) ? GDK_SUCCEED : GDK_FAIL; }
+int +CMDbandmergejoin(BAT **result, BAT *left, BAT *right, ptr minus, ptr
bit *li, bit *hi) +{ + return (*result = BATbandmergejoin(left, right, minus, plus, *li, *hi)) ? GDK_SUCCEED : GDK_FAIL; +} + +int +CMDbandmergejoin_limit(BAT **result, BAT *left, BAT *right, ptr minus,
I noticed it was for PF_ROX, and that does pose a problem. It seems that the PF_ROX branch should depend on the current version of MonetDB and not on the stable version. than plus, ptr
plus, bit *li, bit *hi, lng* limit) +{ + size_t cutoff = *limit; + *result = BATbandmergejoin_limit(left, right, minus, plus, *li, *hi, &cutoff); + if (*result) { + bat bid = (*result)->batCacheid; + *result = BATnew(TYPE_lng, TYPE_bat, 1); + if (*result) BUNins(*result, &cutoff, &bid, FALSE); + BBPunfix(bid); + } + return (*result)?GDK_SUCCEED:GDK_FAIL; +} + +int +CMDleftmergejoin_limit(BAT **result, BAT *left, BAT *right, lng* limit) +{ + size_t cutoff = *limit; + *result = BATleftmergejoin_limit(left, right, cutoff, &cutoff); + if (*result) { + bat bid = (*result)->batCacheid; + *result = BATnew(TYPE_lng, TYPE_bat, 1); + if (*result) BUNins(*result, &cutoff, &bid, FALSE); + BBPunfix(bid); + } + return (*result)?GDK_SUCCEED:GDK_FAIL; +} + @= selectcmd int CMDord_@1select1(BAT **result, BAT* b, ptr value) { return (*result = BAT_select_(b, value, 0, TRUE, TRUE, @2, FALSE, TRUE))?GDK_SUCCEED:GDK_FAIL;
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
-- Sjoerd Mullender
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
-- Sjoerd Mullender ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Monetdb-checkins mailing list Monetdb-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-checkins