Tolog optimization
Upcoming SlideShare
Loading in...5

Tolog optimization



A short talk on the tolog optimizations that Ontopia performs

A short talk on the tolog optimizations that Ontopia performs



Total Views
Views on SlideShare
Embed Views



2 Embeds 277 276 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Tolog optimization Tolog optimization Presentation Transcript

    • The tolog optimizations in Ontopia
      TMRA, 2010-09-30
      Lars Marius Garshol
    • Query reordering
      Changes the order in which clauses are executed
      Can make an enormous difference to execution speed
      Uses simple cost estimation
      there are two estimators in Ontopia
      o:composed_by($OPERA : o:Work, $COMPOSER : o:Composer),
      o:based_on($OPERA : o:Result, $WORK : o:Source),
      o:written_by($WORK : o:Work, o:Shakespeare : o:Writer)
    • Hierarchy walker
      Recursive rules do a lot of unnecessary work
      when evaluating rules using the normal algorithm
      essentially, already discarded matches come back again
      Recursive rules usually consist of wrapping, and a recursion step
      the optimizer finds the recursion step,
      then runs a transitive closure of it by "pumping" matches through the recursive step
      Greatly improves the speed of hierarchical queries
    • Rule inlining
      Given a query like
      composed-by($C, $O) :- composed-by($C : composer, $O : work).
      select $OPERA from composed-by(puccini, $OPERA)?
      the optimizer inlines the rule
      this gets rid of the overhead involved in calling the rule
      Could be extended to handling bigger rules, but this is tricky
    • Duplicate remover
      This optimizer inserts a "fake" predicate which removes duplicate temporary results
      It analyzes queries to see which ones would benefit from the removal
      At the moment it only does this with recursive rules
      The effect there can be enormous
    • String prefix searches
      Consider the query
      ph:time-taken($PHOTO, $DATE),
      $DATE < %time%
      order by $DATE desc limit 1?
      It has to
      find all photos,
      throw away the ones that are too late in time,
      sort the remainder,
      then keep the first
      The optimizer rewrites this into an index lookup using an ordered index on occurrence values
      it then pushes all topics with the correct value in increasing order, through the query predicate until it finds enough matches to satisfy the "limit"
    • Faster role access
      Given a query that contains
      role-player($R1, fixed-point),
      type($R1, roletype),
      the optimizer rewrites this into
      ... role-player($R1, fixed-point <, roletype>)
      so that the engine can use a faster method in the API, saving lots of temporary results