I looked at your messages.log
You should probably configure the memory mapping to use:
(conf/neo4j.properties)
neostore.nodestore.db.mapped_memory=100M
neostore.relationshipstore.db.mapped_memory=1G
neostore.propertystore.db.mapped_memory=1G
neostore.propertystore.db.strings.mapped_memory=200M
neostore.propertystore.db.arrays.mapped_memory=0M
neostore.relationshipgroupstore.db.mapped_memory=10M
On Mon, Nov 24, 2014 at 9:34 AM, Michael Hunger <
michael.hun...@neotechnology.com> wrote:
> :schema is for the neo4j browser
> for the shell and the /webadmin console it is "schema"
>
> How many of both of the nodes are there?
>
> MATCH (assy:Assy {k_ebene: 'MODEL'}) return count(*);
> MATCH (mat:Mat {m_matnr: "A4420380071"}) return count(*) ;
>
> I'll ask the Cypher team about the bug.
>
>
> Yes, the Java traversal would be many times faster,
>
> Either just going backwards from :Mat via
> node.getRelationships(Direction.INCOMING,
> DynamicRelationshipType.withName("HAS")) and then using rel.getStartNode()
> for the next level.
> Or using ShortestPath between the two
> Or using the TraversalDescription with the limit on relationship-type and
> direction
>
>
> On Mon, Nov 24, 2014 at 8:53 AM, <m...@docware.de> wrote:
>
>> Hello Michael,
>>
>> thanks already for your support:
>>
>> Am Sonntag, 23. November 2014 12:04:33 UTC+1 schrieb Michael Hunger:
>>>
>>> Just a few questions:
>>>
>>> * can you share your graph.db/messages.log for diagnostics on config.
>>>
>>>
>> it's attached
>>>
>>
>>
>>> * do you run your queries in the browser? or via the neo4j-shell? or
>>> from a program?
>>> in Browser at adress http://localhost:7474/webadmin/ (Data Browser)
>>>
>>
>>
>>> * what does the output of :schema look like?
>>>
>> Sorry, I don't know what you mean. Entering ":schema" gives an error.
>>
> "schema" in the shell
>
>>
>>> * what is the maximum depth in your tree?
>>> 5 in the actual case; for other DBs it could be deeper but deeper than
>>> 10 would be unlikely
>>>
>>
>>
>>> * can you try to prefix your query with cypher 2.1.experimental (which
>>> is the new query planner)
>>>
>> Yeah, 1,8s compared to 11s :-)
>>
>>>
>>> * as you bound both nodes and you have a tree, what you're interested in
>>> is the shortest path between those (I think)
>>>
>>> MATCH (assy:Assy {k_ebene: 'MODEL'}), (mat:Mat {m_matnr: "A4420380071"})
>>> MATCH shortestPath((assy)-[:HAS*..]->(mat))
>>> RETURN distinct assy.k_vari order by assy.k_vari limit 1000
>>>
>>> This is slower, took 72s
>>
> hmm interesting, perhaps the two node-counts form a cross-product
>
>
>> Our graphs are always shortest paths without need to specifying this.
>> Once a "MODEL" node have been reached, there are no more "MODEL" nodes
>> deeper.
>>
>>
>>> * how many paths does this return?
>>>
>>> MATCH (assy:Assy {k_ebene: 'MODEL'})-[:HAS*..]->(mat:Mat {m_matnr:
>>> "A4420380071"})
>>> RETURN count(*)
>>>
>>> ca. 28000
>>
>>
>>> I asusme that :Mat is more selective, so can you try using:
>>>
>>> MATCH (assy:Assy {k_ebene: 'MODEL'})-[:HAS*..]->(mat:Mat {m_matnr:
>>> "A4420380071"})
>>> USING INDEX mat:Mat(m_matnr)
>>> RETURN count(*)
>>>
>>> no difference
>>
> -> I meant in timing not in count :)
>
>>
>>
>>> Depending the # of returned paths, sorting all of them by assy.k_vari
>>> can take time too, same for creating the distin
>>>
>>> can you try how much time this takes?
>>>
>>> MATCH (assy:Assy {k_ebene: 'MODEL'})-[:HAS*..]->(mat:Mat {m_matnr:
>>> "A4420380071"})
>>> RETURN distinct assy.k_vari
>>>
>>> no difference. I tested already with/without distince and/or order by
>>
>
> yes path matching still has an issue in the current rule based cypher
> impl, while it should actually be instant
>
>>
>>
>
>> So thank you already for telling me how to use the new query planner. Do
>> you think writing a Java custom transversal would further help us? I think
>> of implementing a whitelist/blacklist mechanism as you do for our SQL
>> Server client transversal. There are other situations where the traversal
>> must stop at nodes meeting certain properties. I think this would a reason
>> for a custom transversal tool.
>>
>> Thanks a lot so far
>>
>> Michael S.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Neo4j" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to neo4j+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to neo4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
