Extend PrefilterExpression for Literal and Iri
#1653
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Johannes Kalmbach <[email protected]>
Co-authored-by: Johannes Kalmbach <[email protected]>
Co-authored-by: Johannes Kalmbach <[email protected]>
Co-authored-by: Johannes Kalmbach <[email protected]>
…neral implementation
Co-authored-by: Johannes Kalmbach <[email protected]>
Co-authored-by: Johannes Kalmbach <[email protected]>
…ng correct prefix in Constants.h
The recent implementation of lazy joins introduced a bug that lead to deadlocks if the result of a lazy join was not fully consumed (e.g. because of a LIMIT clause, or because the query was cancelled or an exception occured upstream. This PR fixes that bug. Co-authored-by: Johannes Kalmbach <[email protected]>
…urg#1646) An update can invalidate a cached query result in the sense that if one would run the query again after the update, the result may be different. This was ignored so far, and is now considered as follows: Each `LocatedTriplesSnapshot` gets its own "index" (starting from zero and then incremented for each new snaphot). That index becomes part of the cache key. That way, a query will make use of a cached result if and only if there was no update between the time of the query and the time when the cached result was computed.
An update can invalidate a cached query result in the sense that if one would run the query again after the update, the result may be different. This was ignored so far, and is now considered as follows: Each `LocatedTriplesSnapshot` gets its own "index" (starting from zero and then incremented for each new snaphot). That index becomes part of the cache key. That way, a query will make use of a cached result if and only if there was no update between the time of the query and the time when the cached result was computed.
… of `Index Scan`s (ad-freiburg#1619) With this PR, filter expressions that can be evaluated via binary search on a sorted input are directly evaluated on the block metadata of an IndexScan. For example in a query that contains `{ ?s ?p ?o FILTER (?o > 3)`} only the blocks of the full index scan (sorted by the object) are read from disk that according to their metadata might contain values `> 3`. Currently this mechanism has the following limitations: 1. It can only be applied if the IndexScan directly is the child of the FILTER clause 2. It can only be applied to logical expressions (AND/OR/NOT) and to relational expressions (greater than, equal to, etc.) between a variable and a constant. Currently the constant can not yet be an IRI or Literal.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1653 +/- ##
==========================================
+ Coverage 89.43% 89.62% +0.18%
==========================================
Files 375 381 +6
Lines 36338 36839 +501
Branches 4100 4162 +62
==========================================
+ Hits 32499 33017 +518
- Misses 2518 2521 +3
+ Partials 1321 1301 -20 ☔ View full report in Codecov by Sentry. |
joka921
requested changes
Dec 3, 2024
joka921
requested changes
Dec 5, 2024
joka921
requested changes
Dec 5, 2024
| using namespace ad_utility; | ||
| constexpr static std::array mirrorPairs{P{LT, GT}, P{LE, GE}, P{GE, LE}, | ||
| P{GT, LT}, P{EQ, EQ}, P{NE, NE}}; | ||
| constexpr ConstexprMap<CompOp, CompOp, 6> mirrorMap(mirrorPairs); |
There was a problem hiding this comment.
Suggested change
| constexpr ConstexprMap<CompOp, CompOp, 6> mirrorMap(mirrorPairs); | |
| constexpr ConstexprMap<CompOp, CompOp, 6> mirrorMap({{LT, GT}, {LE, GE}, ...}); |
(should work , no need for the using P, using namespace and explicit array mirrorPairs.
There was a problem hiding this comment.
W.r.t. the std::pair<CompOp, CompOp> values it seems like that they can't be automatically constructed within an initializer list, still had to use P = std::pair<CompOp, CompOp>.
Conformance check passed ✅No test result changes. |
|
joka921
approved these changes
Dec 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With this PR, the prefilter expressions implemented in #1619 also apply to literals and IRIs. For example the following query only extracts the relevant, prefiltered blocks from the
IndexScan: