Shouldn't multiple identical bind calls be impossible?
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
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-list
Ah! I'll check that out, thanks!
On Thu, Sep 12, 2013 at 4:18 PM, Martin Kersten Martin.Kersten@cwi.nlwrote:
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
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 Martin.Kersten@cwi.nlwrote:
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
Thanks Roberto,
Point taken and, yes, if we would restructure the symbol table, we would be able to look back in time much easier. However, now the bind() operations are not the most expensive ones to consider immediate optimization.
The Constant Optimizer had to be turned off, because apparently at some point the SQL runtime system played with the 'constant' values, killing the property.
regards, Martin On 9/19/13 9:45 AM, Roberto Cornacchia wrote:
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 <Martin.Kersten@cwi.nl mailto:Martin.Kersten@cwi.nl> wrote:
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 <mailto:users-list@monetdb.org> http://mail.monetdb.org/__mailman/listinfo/users-list <http://mail.monetdb.org/mailman/listinfo/users-list> _________________________________________________ users-list mailing list users-list@monetdb.org <mailto:users-list@monetdb.org> http://mail.monetdb.org/__mailman/listinfo/users-list <http://mail.monetdb.org/mailman/listinfo/users-list>
users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
participants (3)
-
Martin Kersten -
Martin Kersten -
Roberto Cornacchia