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

F.temp optimizer and sort order merged (DONT MERGE, but Hannah may test it) #326

Closed

Conversation

joka921
Copy link
Member

@joka921 joka921 commented Apr 19, 2020

No description provided.

- The previous version put all triples and filters that appeared directly in a WHERE clause together.
- this is not correct, since always when an OPTIONAL, UNION, SUBQUERY etc. appears a new scope
  is started. For example in
  SELECT ?x ?y WHERE {
    ?x <is-a> <Scientist>
    OPTIONAL { ?x <Spouse> ?y}
    FILTER ?x < <Ada_Lovelace>
  }
  the filter should have no effect, because it is not in the same scope as the x is a scientist triple.
  the probably more useful query would be
  SELECT ?x ?y WHERE {
    ?x <is-a> <Scientist> .
    FILTER ?x < <Ada_Lovelace>
    OPTIONAL { ?x <Spouse> ?y}
  }
  where the filter is actually applied on the entities that are scientists.
  However, QLever previously handled these queries both in the second way.

- To correct this, implemented a BasicGraphPattern (triples, filters and values that are "directly" in the Body of another graph pattern or a WHERE clause) class.
  BasicGraphPatterns are also children of their parent body.

- In addition, Optionals were also treated wrong as the GraphPatterns must be treated in order which makes a difference for Optionals.

- This version of the QueryPlanner does some degree of optimization, however one could optimize multiple adjacent GraphPatterns that are not Optional, if their
  scopes are respected.

- TODO: There still are bugs in the handling of optionals as the SPARQL standard knows "unbound values" which can be rebound, e.g.

  SELECT ?x ?name WHERE {
    ?x <is-a> <human>
    OPTIONAL {?x <TwitterAccount> ?name}
    OPTIONAL {?x rdfs:label ?name }
  }
  which should only add the names only for humans that don't have twitter accounts and the handling of the empty query
  SELECT ?x WHERE {} (1 result where ?x is unbound/NULL)

- TODO: Some candidate plans found by optimizing a TransitivePath are currently unable to be joined with adjacent patterns.
        It seems that we can always find a suitable candidate, so that this works, but we still should inspect, whether this is the correct behavior.
…type of GraphPatternOperation.

The parser already compiles.
TODO: clean up, self-review, commit messages and squash/rewrite history.
…identical again.

Next step: make merge call join.
TODO<Hannah> checkout how this performs on the Wikidata evaluation.
TODO: squash, git history and then self-review (but first let them do the ParsedQuery stuff.)
…ern trick in cases where it was actually legal.
…rack down the strange error of prefix filters.
All other types of filter disjunctions will currently lead to parse errors since they are harder to properly evaluate and to estimate during planning.
# Conflicts:
#	src/engine/Filter.cpp
#	src/parser/SparqlParser.cpp
All other types of filter disjunctions will currently lead to parse errors since they are harder to properly evaluate and to estimate during planning.
…OrderMerged

# Conflicts:
#	e2e/scientists_queries.yaml
TODO: merge with the new optimizer to properly include it,
and make this all work and test it.
# Conflicts:
#	src/parser/ParsedQuery.h
f compile. Not yet done at all.
joka921 added 27 commits May 10, 2020 21:00
TODO: cleanUp + verification + Optimization for Max.
TODO: limit the number of threads and make it configurable.
# Conflicts:
#	src/engine/QueryPlanner.cpp
#	src/parser/ParsedQuery.cpp
#	src/parser/ParsedQuery.h
#	test/QueryPlannerTest.cpp
- The syntax is BIND ("Some String" AS ?new_variable)
# Conflicts:
#	src/engine/GroupBy.cpp
#	src/engine/QueryPlanner.cpp
#	src/parser/ParsedQuery.h
#	test/QueryPlannerTest.cpp
@joka921
Copy link
Member Author

joka921 commented Nov 28, 2020

There is a newer version of this "One for everything TEMP pr, close this one.

@joka921 joka921 closed this Nov 28, 2020
@joka921 joka921 deleted the f.TempOptimizerAndSortOrderMerged branch May 8, 2021 07:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant