Details
-
Wish
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
For certain requirements it would be good to have a notion/support to deduce query shape [1]
A combination of query predicate, sort, and projection specifications.
For the query predicate, only the structure of the predicate, including the field names, are significant; the values in the query predicate are insignificant. As such, a query predicate { type: 'food' } is equivalent to the query predicate { type: 'utensil' } for a query shape.
So transforming that to Oak the shape should represent a JCR-SQL2 query string (xpath query gets transformed to SQL2) which is a canonical representation of actual query ignoring the property restriction values.
Example we have 2 queries
- SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] = 'published'
- SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] = 'disabled'
The query shape would be
SELECT * FROM [app:Asset] AS a WHERE a.[jcr:content/metadata/status] = 'A'. The plan for query having given shape would remain same irrespective of value of property restrictions. Path restriction can cause some difference though
The shape can then be used for
- Stats Collection - Currently stats collection gets overflown if same query with different value gets invoked
- Allow configuring hints - See support in Mongo [2] for an example. One specify via config that for a query of such and such shape this index should be used
- Less noisy diagnostics - If a query gets invoked with bad plan the QE can log the warning once instead of logging it for each query invocation involving different values.
[1] https://docs.mongodb.com/manual/reference/glossary/#term-query-shape
[2] https://docs.mongodb.com/manual/reference/command/planCacheSetFilter/
