Hi Martin,
Just a quick follow up on that.
In opt_commonTerms.c, there is indeed a limit on the search space:
cnt = mb->stop / 128 < 32? 32 : mb->stop/128; /* limit search depth */
Pity that this is hardcoded, but I understand you had to defend the system
from unreasonably long search.
Pity also that the longer the initial mal plan, the more candidates for
reuse the optimizer risks to miss - a bit contradictory in a way, because
long plans are exactly those we would like to shrink with this optimizer.
I noticed this in the initial comment:
/*
..
* It requires the constant optimizer to be ran first.
*/
However, the constants optimizer is currently not in the system-defined
pipelines, at all.
I suppose this is just an outdated comment?
Best,
Roberto
On Thu, Sep 12, 2013 at 4:18 PM, Martin Kersten
Depends on the distance in the plan. Currently there is a window limit to search for constants in the symbol tables. See defConstant.
On 9/12/13 12:46 PM, Roberto Cornacchia wrote:
I'd like to ask a simple question before reporting what I suspect to be a bug.
On a Feb2013, using default_pipe (same holds for no_mitosis and sequential pipes), no matter what the query and the data schema look like (really, that shouldn't matter here), is it for any reason possible to have a MAL plan with repeated, identical bind operations?
Like this:
function user.s4_1():void; ... X_40 := sql.bind(X_1,"spinque","dict",**"idstr",0); ... X_126 := sql.bind(X_1,"spinque","dict",**"idstr",0); ... X_298 := sql.bind(X_1,"spinque","dict",**"idstr",0); .. X_384 := sql.bind(X_1,"spinque","dict",**"idstr",0); ...
... and so on
My understanding is: with commonTerms optimizer enabled (I'm just using the standard pipes), there should be no way to see those calls repeated: - they have no side-effects - they do not depend on any user data
Why isn't the first bind reused in the rest of the plan?
Of course my worries are not much about those calls per se, which are super fast, but about my suspicion that entire subqueries built on top of such binds are replicated unnecessarily. I don't want to focus on the actual query here, because if I am correct (please correct me otherwise), the situation above is already enough to submit a more complete bug report.
By the way, another suspicious instruction that I see in my MAL plan is:
X_25 := X_24;
Shouldn't this be removed by the aliases optimizer?
Best, Roberto
______________________________**_________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/**mailman/listinfo/users-listhttp://mail.monetdb.org/mailman/listinfo/users-list
______________________________**_________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/**mailman/listinfo/users-listhttp://mail.monetdb.org/mailman/listinfo/users-list