public static interface StatementPatternNode.Annotations extends GroupMemberNodeBase.Annotations, IJoinNode.Annotations
Modifier and Type | Field and Description |
---|---|
static boolean |
DEFAULT_DISTINCT |
static String |
DISTINCT
Boolean flag indicates that the distinct solutions for the statement
pattern are required (false).
|
static String |
DISTINCT_TERM_SCAN_VAR
An optional annotation whose value the variable that will be bound by
a
DistinctTermAdvancer layered over the access path. |
static String |
EXISTS
The existence of at least one solution will be verified otherwise the
solution will be failed.
|
static String |
FAST_RANGE_COUNT_VAR
An optional annotation whose value is a variable which will become
bound to the fast range count of the associated triple pattern.
|
static String |
INLINE
The data for this access path is inline.
|
static String |
RANGE
An optional attribute whose value is an
RangeBOp which models
the key-range constraint on the access path. |
static String |
SCOPE
The
StatementPattern.Scope (required). |
static String |
SID
An optional annotation whose value is the variable which will be
bound to the statement identifier for the matched statement patterns.
|
QUERY_HINTS
DEFAULT_MINUS, DEFAULT_OPTIONAL, FILTERS, MINUS, OPTIONAL
static final String SCOPE
StatementPattern.Scope
(required).ASTGraphGroupOptimizer
,
Constant Field Valuesstatic final String DISTINCT
Note: This is a hint that the DistinctTermAdvancer
should be
used to visit the distinct ISPO
s having a common prefix. This
is used for GRAPH ?g {}
, which evaluates to all of the
named graphs in the database (if the named graphs were not explicitly
specified).
Note: For only partly historical reasons, this is not used to mark default graph access. A default graph access path strips the context and then applies a DISTINCT filter to the resulting triples.
static final boolean DEFAULT_DISTINCT
static final String EXISTS
SPOAccessPath
.
Note: This is used in combination with a join against an inline access path for the named graphs. The "exists" statement pattern MUST run after the access path which produces the variety since it will be used to constrain that as-bound variety. This the join order in query plan must look like:
(_,_,_,?g)[@INLINE,@IN(g,namedGraphs)] x (_,_,_,?g)[@EXISTS]rather than
(_,_,_,?g)[@EXISTS] x (_,_,_,?g)[@INLINE,@IN(g,namedGraphs)]as the latter will find only one solution for
?g
.(Optimization for GRAPH uri {} and GRAPH ?foo {})
,
Constant Field Valuesstatic final String INLINE
IN(var,values)
. The IN filter could be
attached to IJoinNode.Annotations.FILTERS
or it could be the value of this
attribute.
We also have use cases for inline solution set access paths for use
with the samples materialized by the RTO. Those should be an
HTree
and the data should be modeled as ISolution
s.
(Note that some vertices may correspond to "bop fragment" joins, in
which case the can not be modeled as ISPO
s.)
Both the column projection (IN) and the inline solution set (HTree)
are simpler access paths. They only support element visitation, a
full scan of the access path (this is the same as saying that there
are no join variables), or probing to find all solutions which join
on some join variable(s). This is in contrast to the
SPOAccessPath
, which supports key-range constraints (prefix)
and range constraints (prefix with key range on a data type value).
(Optimization for GRAPH uri {} and GRAPH ?foo {})
,
Constant Field Valuesstatic final String RANGE
RangeBOp
which models
the key-range constraint on the access path. The RangeBOp
is
used when there are filters which impose a GT/GTE and/or LT/LTE
restriction on the values which a variable may take on for that
access path.
TODO We should also handle datatype constraints on a variable here.
For example, if a variable is known to be numeric, or known to be
xsd:int, then we can immediately reject any bindings which would
violate that type constraint. To do this right, we need to notice
those type constraints and propagate them backwards in the plan so we
can reject bindings as early as possible. (In fact, we can also do a
range constraint which spans each of the datatypes which the variable
could take on. Datatype constraints and value range constraints are
very much related. The datatype constraint is effectively a value
range constraint allowing the entire value space for that datatype.
Likewise, a value range constraint must be applied across the UNION
of the allowable ground datatypes for the variable.)ASTRangeConstraintOptimizer
,
(lift range
constraints onto AP)
,
Constant Field Valuesstatic final String SID
static final String FAST_RANGE_COUNT_VAR
static final String DISTINCT_TERM_SCAN_VAR
DistinctTermAdvancer
layered over the access path.Copyright © 2006–2019 SYSTAP, LLC DBA Blazegraph. All rights reserved.