Hello,
I was able to speed up the queries by enable
relationship_auto_indexing=true
relationship_keys_indexable=StartDate,EndDate
And also by adding Using index on those queries that have "In" and "Equals =".
The other thing I did is to not have possibility of null not thereby speeding the query.
Thanks for the help.
Indexes for relationships are in discussion but no decision made yet.
Your point about adding a label for ":Current" or ":Active" nodes would make a big difference.
As checking the label is really fast compared to props.
for the comparison expression
comparing something with null is always false and NOT() of that is always true
that's why I thought it could help.
Michael
Am 19.03.2015 um 11:25 schrieb Ryan John Velasco <
ry...@limesource.se >:
Please see my comments.
I wonder why it doesn't use the index on :Company.ID -> it says it uses a Label-Scan instead.
can you please run ":schema" in the browser
can you expand all operations?
and perhaps try this hint after the match
USING INDEX T0:Company(ID)
?
> Am 19.03.2015 um 10:30 schrieb Ryan John Velasco <
ry...@limesource.se >:
>
> I put Index on all nodes. StartDate and End Date are on relationship but sadly relationship doesn't also have index and also your index is like a hash table right?
the index is a b-tree
Thanks for answering this. Is there a plan to also support range query index for relationship? All our relationship have start and end date.
> We decided not to make Time Tree because our use case it range type and it will complicate our queries. It is also difficult during exporting because a node is not valid for certain date but a range of date.
ok
> The solution I have in mind for now to have smaller set of result is to have a relationship type for example for Knows relationship to have KnowsPossiblyValidForTheMoment and KnowsEnded
I don't understand?
Example is that Subscription will have SubscriptionPossiblyValidForTheMoment (during export we will check if the start and end date is already past and if not then it could be valid for the future.
Most of our queries work with relationship that is valid for the moment. so instead of queries like (subscription)-[]-() we can use (SubscriptionPossiblyValidForTheMoment )-[]-() to have smaller subset of nodes by using label or relationship type.
btw you can probably simplify your query by using
>> (T4.StartDate IS NULL or T4.StartDate <= 635623428460000000)
->
>> NOT(T4.StartDate > 635623428460000000)
as for NULL values the comparison evaluates to false and so the total expression will be true
not sure if that helps
So if T4.StartDate is null it will be true right? This will help. Will this makes the query faster? So this will also work NOT(T4.EndDate< 635623428460000000)
>
> Best Regards,
> Ryan
>
> ----- Original Message -----
> From: "Michael Hunger" <
michael...@neotechnology.com >
> To: "Ryan John Velasco" <
ry...@limesource.se >
> Sent: Thursday, March 19, 2015 4:44:16 PM
> Subject: Re: [Neo4j] How does query profiler work?
>
> What is the profile/explain output?
>
> Depending on your data this can result in many billions of paths to be checked
>
> Add directions to your rels
>
> Is there an index/constraint on :Company.ID ? Add one if not
>
> In general all your _nodes_ can be attached to a time tree
>
>
> Von meinem iPhone gesendet
> <explain.png><plan.png>