Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reordering optimizer makes query much slower #93

Closed
GoogleCodeExporter opened this issue Mar 16, 2015 · 2 comments
Closed

Reordering optimizer makes query much slower #93

GoogleCodeExporter opened this issue Mar 16, 2015 · 2 comments

Comments

@GoogleCodeExporter
Copy link

GoogleCodeExporter commented Mar 16, 2015

The following is the query:

/* #OPTION: optimizer.reorder = false */
  using ph      for i"http://psi.garshol.priv.no/tmphoto/"
  using op      for i"http://psi.ontopedia.net/"
  import "http://psi.ontopia.net/tolog/string/" as str

  year($DATE, $YEAR) :-
    str:substring($YEAR, $DATE, 0, 4).

  select $EVENT, $SDATE, $EDATE, $YEAR, count($PHOTO) from
    instance-of($EVENT, op:Event),
      not(ph:hide($EVENT : ph:hidden)),
    { ph:start-date($EVENT, $SDATE) },
    { ph:end-date($EVENT, $EDATE) },
    { year($SDATE, $YEAR) | not(year($SDATE, $YEAR)) },
    ph:taken-during($PHOTO : op:Image, $EVENT : op:Event)
  order by $YEAR desc, $SDATE desc?

The reordering optimizer makes the ph:taken-during go before the not(), 
which increases the execution time from 40 millisecs to 4300 millisecs. 

It should be possible to solve this.

Original issue reported on code.google.com by lar...@gmail.com on 26 Jul 2009 at 5:23

@GoogleCodeExporter
Copy link
Author

GoogleCodeExporter commented Mar 16, 2015

Both the predicate-based and the old optimizer get this wrong. The old 
optimizer 
even makes the query crash with "Variable $SDATE not bound in predicate 
substring" 
by running the year {OR} too early.

With the predicate-based optimizer, after the first predicate is chosen (to be 
instance-of, setting $EVENT), the not() clause is evaluated as INFINITE_RESULT 
+ 2, 
while taken-during is evaluated as MEDIUM_RESULT + 1. It turns out that the 
reason 
for this is that not()-clauses are *always* set to INFINITE_RESULT+2. 
Obviously, it 
is possible to do better.

Changed the approach taken in revision 543, which solves this problem, and 
cannot 
possibly introduce any new ones. However, it is probably still too conservative.

Original comment by lar...@gmail.com on 12 Oct 2009 at 11:33

@GoogleCodeExporter
Copy link
Author

GoogleCodeExporter commented Mar 16, 2015

Original comment by lar...@gmail.com on 12 Oct 2009 at 11:34

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant