The two databases store the graphs with same graph structure. Each node has 
only one label. The two graphs have 2 and 100 labels respectively, named 
with GRAPH_0, GRAPH_1, .., etc.

The first query is "profile match (a0:GRAPH_0)-->(a1:GRAPH_1) return 
id(a0), id(a1)". The second one is "profile match 
(a0:GRAPH_2)-->(a1:GRAPH_1) return id(a0), id(a1)".

Their query plans are as follows:

+------------------+----------------+---------+---------+------------------------------------+----------------------------------------------------+
| Operator         | Estimated Rows | Rows    | DB Hits | Variables         
                 | Other                                              |
+------------------+----------------+---------+---------+------------------------------------+----------------------------------------------------+
| +ProduceResults  |        3298257 | 2638399 |       0 | id(a0), id(a1)   
                  | id(a0), id(a1)                                     |
| |               
 
+----------------+---------+---------+------------------------------------+----------------------------------------------------+
| +Projection      |        3298257 | 2638399 |       0 | id(a0), id(a1) -- 
anon[19], a0, a1 | {id(a0) : IdFunction(a0), id(a1) : IdFunction(a1)} |
| |               
 
+----------------+---------+---------+------------------------------------+----------------------------------------------------+
| +Filter          |        3298257 | 2638399 | 3298257 | anon[19], a0, a1 
                  | a1:GRAPH_1                                         |
| |               
 
+----------------+---------+---------+------------------------------------+----------------------------------------------------+
| +Expand(All)     |        3298257 | 3298257 | 4053211 | anon[19], a1 -- 
a0                 | (a0)-->(a1)                                        |
| |               
 
+----------------+---------+---------+------------------------------------+----------------------------------------------------+
| +NodeByLabelScan |         754954 |  754954 |  754955 | a0               
                  | :GRAPH_0                                           |
+------------------+----------------+---------+---------+------------------------------------+----------------------------------------------------+


+------------------+----------------+-------+---------+------------------------------------+----------------------------------------------------+
| Operator         | Estimated Rows | Rows  | DB Hits | Variables           
               | Other                                              |
+------------------+----------------+-------+---------+------------------------------------+----------------------------------------------------+
| +ProduceResults  |          33082 | 26410 |       0 | id(a0), id(a1)     
                | id(a0), id(a1)                                     |
| |               
 
+----------------+-------+---------+------------------------------------+----------------------------------------------------+
| +Projection      |          33082 | 26410 |       0 | id(a0), id(a1) -- 
anon[19], a0, a1 | {id(a0) : IdFunction(a0), id(a1) : IdFunction(a1)} |
| |               
 
+----------------+-------+---------+------------------------------------+----------------------------------------------------+
| +Filter          |          33082 | 26410 |   33082 | anon[19], a0, a1   
                | a1:GRAPH_1                                         |
| |               
 
+----------------+-------+---------+------------------------------------+----------------------------------------------------+
| +Expand(All)     |          33082 | 33082 |   40735 | anon[19], a1 -- a0 
                | (a0)-->(a1)                                        |
| |               
 
+----------------+-------+---------+------------------------------------+----------------------------------------------------+
| +NodeByLabelScan |           7653 |  7653 |    7654 | a0                 
                | :GRAPH_2                                           |
+------------------+----------------+-------+---------+------------------------------------+----------------------------------------------------+

On Friday, August 4, 2017 at 4:20:52 AM UTC-7, Michael Hunger wrote:
>
> You need to supply more details, i.e. the queries, query plans, query 
> times, how many labels you have per node etc.
>
> Michael
>
> On Fri, Aug 4, 2017 at 7:02 AM, Sun Yuhan <wdmz...@gmail.com <javascript:>
> > wrote:
>
>> I tested the query like (a:A) --> (b:B) in two graphs. The two graphs 
>> have the same graph structure, which means same number of nodes and edges. 
>> The edges are connecting the same two nodes in the two graphs. The only 
>> difference is that the first graph has only two labels A and B and the 
>> second graph has ten different labels, which is from A to I. For this same 
>> query, query time in the second graph is about 30x worse than that in the 
>> first graph.
>>
>> Is there any feasible explanation for this?
>>
>> On Thursday, July 6, 2017 at 9:10:24 PM UTC-7, Michael Hunger wrote:
>>>
>>> The index lookup is used when using labels with properties
>>> The label scan store that I described is used for all label scan 
>>>
>>> Von meinem iPhone gesendet
>>>
>>> Am 07.07.2017 um 03:31 schrieb Sun Yuhan <wdmz...@gmail.com>:
>>>
>>> Actually I am using the neo4j to execute some graph pattern query ( 
>>> subgraph isomorphism). So the given query pattern will be a labeled graph 
>>> and the results are all subgraphs in the database that can fit the pattern. 
>>> Does the index you mentioned in the reply can achieve better performance 
>>> than using labels?
>>>
>>> On Wednesday, July 5, 2017 at 1:32:15 AM UTC-7, Michael Hunger wrote:
>>>>
>>>> It should be a rare operation if you have indexes in place
>>>>
>>>> There is a reverse store mapping labels to sets of node ids
>>>>
>>>> In 3.1 it uses a compressed lucene format 
>>>> In 3.2 a custom generational b+ tree
>>>> Details for both are only in the source
>>>>
>>>>
>>>>
>>>> Von meinem iPhone gesendet
>>>>
>>>> Am 05.07.2017 um 07:31 schrieb Sun Yuhan <wdmz...@gmail.com>:
>>>>
>>>> The NodeByLabelScan is very commonly used in cypher query execution 
>>>> plans. However, it is not clear how this operation is executed in neo4j. 
>>>>
>>>> What's more, I do not know how the label is managed and stored in 
>>>> neo4j. Are there any materials online that I can refer to? Or I can refer 
>>>> to some source code of neo4j to see the implementation details.
>>>>
>>>> -- 
>>>> 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+un...@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+un...@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+un...@googlegroups.com <javascript:>.
>> 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.

Reply via email to