Considering the new index types (range index instead of BTREE index) from version >= 5 on and the very brief documentation (Temporal values - Cypher Manual):
All temporal types can be indexed, and thereby support exact lookups for equality predicates. Indexes for temporal instant types additionally support range lookups.
I should create a normal index on a datetime field (d on a node of type Val) like
CREATE INDEX value_datetime_index FOR ( v:Val) ON (v.d);
which will help for operations like v.d > datetime({year: <year>, month: <month>, day: <day>})?
We have a bunch of values on a daily basis, so roughly 365 each year and we mostly look for values an end of months or years. We should consider to use a time series DB, I know, but is a normal range index suitable for this situation?
Finally: the best way to check the impact of an index by prefixing any query with PROFILE, right?
More specifically, I have this structure (:MeasurementSite)--(:Meter)--(:Val) where any meter has edges to many values. When I use the following query (part): `MATCH (m:MeasurementSite)--(:Meter)--(v:Val) WHERE ID(m) = $meter AND v.d < $end AND v.d > $start RETURN v;`
I can see this operators in the execution plan:
| +Filter | 3 | NOT anon_2 = anon_0 AND (cache[v.d] < $end AND cache[v.d] > $start) AND v:Val | 0 | 38 | 1037 | | 0/0 |
the range index is fine for this, nothing wrong with that part. the planner just wont lead with an index seek on Val when the query starts from a single MeasurementSite and expands outward, expanding is cheaper so it filters afterwards. the gotcha to check is the parameter types: if $start and $end arent actual datetime values the index cant be used for the range lookup at all. also try PROFILE with the Val pattern first, matching (v:Val) on the date range before expanding to the site, and see if the plan flips to a NodeIndexSeek.
