This is a feature request to identify options for an improved EXPLAIN. The current EXPLAIN provides a lot of low level information about query plan performance. However, it does not do any of the following (options that have been implemented already are marked through strikethrough):
- Identify if the query is bad (e.g., if it requires bottom up evaluation, has unconstrained cross products, ill-formed joins arising from a lack of a shared variable).
Identify cases where a variable is visible in the outer scope (bindings are produced), but is not bound within the inner scope (no binding producers) and therefore is not visible when evaluating in a FILTER or similar expression in the inner scope.
- Identify cases where a variable is bound using BIND() but not projected into a UNION (or other nested subgroup) and hence the subgroup runs with the variable unconstrained and then applies the BIND.
- Identify if a better join order was available (the RTO can do this, but more work is required for quads mode RTO support and for rewriting sub-selects and aggregations such that we can apply the RTO to all queries).
- Identify if a query will have a long run time. If so, static analysis could spend more time on the query, we could automatically enable the analytic query mode, use the RTO, etc.
- Identify if there are plan alternatives that are more efficient and what query hints could be added or removed to improve the plan execution.
- Identify if the query plan failed to push down a filter or optimize a particular expression.
- Identify for a workload which queries are responsible for most of the workload of the database.
- Identify constructs that are not optimizable (such as FILTER ?x="some string", which is not inlinable easily in the general case), to give the user the opportunity to rewrite the query into a more precise one
- Graphical representation of query plan
- Mark JOINs and FILTERs that are expensive and do not change the intermediate cardinality. People often write queries that are redundant in this sense.
Mark patterns where statement pattern (or other group nodes) cannot be moved in front of optional -> this might be an ill designed pattern Mark patterns where MINUS is used in an unsatisfiable/always satisifed way -> this might not be the query the author wanted to write Mark FILTERs where the variable is out of scope (and thus will never be bound)
- Indicate projection variables that are not mentioned inside the query (or are not in the main scope) and thus can never be bound in the result