For the issue you ran into, if you leave off the DISTINCT it should work
and this as well
cypher 2.1.experimental
MATCH (assy:Assy { k_ebene: 'MODEL' })-[:HAS*..]->(mat:Mat { m_matnr:
"A4420380071" })
WITH DISTINCT assy.k_vari AS k_vari
RETURN k_vari
ORDER BY k_vari
LIMIT 1000
On Mon, Nov 24, 2014 at 9:59 AM, Michael Hunger <
michael.hun...@neotechnology.com> wrote:
> 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.
