The query optimizer is disabled. The joins in the query will be evaluated
in the order in which they are given. This may be used to compensate when
the static query optimizer produces an inefficient join ordering.
A query optimizer based on a static analysis of the query which relies on
fast range counts for the basic graph patterns to estimate the
cardinality of the different access paths. This optimizer is fast but it
can fail to order joins correctly as the error in the estimated
cardinality of joins can grow exponentially in the number of joins in the
A runtime query optimizer based on sampling. The runtime query optimizer
samples each of the access paths and each of the joins and builds out
join paths in a breadth first manner until it finds a join ordering which
is known to dominate the other possible join orderings. The runtime query
optimizer takes into account the actual cardinality and correlation in
the query and the data selected by that query. The runtime query
optimizer can have slightly more overhead than the static query
optimizer, but it never produces a bad join ordering and often identifies
the best join ordering. For cases where the static
query optimizer produces a bad join ordering, the runtime query optimizer
can find join orderings which are orders of magnitude more efficient (10x
or 100x). For long running joins, this can translates into a savings of
minutes or hours.
Returns the enum constant of this type with the specified name.
The string must match exactly an identifier used to declare an
enum constant in this type. (Extraneous whitespace characters are
name - the name of the enum constant to be returned.