: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, <[email protected]> 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to