Was expecting query.log for a apoc.periodic.iterate involving a MERGE would report a waiting: time of 0 when I'm the only user connected to the database
foreach ( x in range (1,300000) | create (n:TxnDetail {id: x , vendorId: toInteger(rand()*500)}));
foreach ( x in range (300001,600000) | create (n:TxnDetail {id: x , vendorId: toInteger(rand()*500)}));
foreach ( x in range (600001,900000) | create (n:TxnDetail {id: x , vendorId: toInteger(rand()*500)}));
foreach ( x in range (900001,1200000) | create (n:TxnDetail {id: x , vendorId: toInteger(rand()*500)}));
foreach ( x in range (1,500) | create (n:Vendor {id:x}));
create index on :Vendor(id);
create index on :TxnDetail(vendorId);
call db.awaitIndexes(1200);
run as a single cypher txn as
neo4j> cypher runtime=slotted MATCH (v:Vendor), (txn:TxnDetail) WHERE txn.vendorId = v.id MERGE (txn)-[:VENDOR]->(v);
0 rows available after 259265 ms, consumed after another 0 ms
Created 1197613 relationships
query.log reports: note waiting=0, for example from the query.log
waiting? 169k msec? ??? but this is a local instance and no one else is connected but me? so is waiting reporting a correct number? waiting for what? as I'm the only one connected.
which is really odd for although 'waiting:' is much smaller then the apoc.periodic.iterate first mentioned above, the 2 page hits ???
in the end I'm trying to determine the fastest way to create/merge a relationship from TxnDetail to Vendor where the vendorId is recorded in the TxnDetail
Specifications (Mandatory)
7G total RAM
dbms.memory.heap.initial_size=3g
dbms.memory.heap.max_size=3g
dbms.memory.pagecache.size=2g
Expected Behavior (Mandatory)
Was expecting query.log for a apoc.periodic.iterate involving a MERGE would report a
waiting:
time of 0 when I'm the only user connected to the databaseActual Behavior (Mandatory)
waiting time is reported >0 , for example
How to Reproduce the Problem
Using Neo4j 3.5.14 / APOC apoc-3.5.0.6-all.jar
query.log reports: note waiting=0, for example from the query.log
so 292k ms for APOC vs 259kms for a single txn but also query.log reports
waiting? 169k msec? ??? but this is a local instance and no one else is connected but me? so is waiting reporting a correct number? waiting for what? as I'm the only one connected.
I also tried
which is even longer. and its query.log entry appears as
which is really odd for although 'waiting:' is much smaller then the apoc.periodic.iterate first mentioned above, the
2 page hits
???in the end I'm trying to determine the fastest way to create/merge a relationship from TxnDetail to Vendor where the vendorId is recorded in the TxnDetail
Specifications (Mandatory)
7G total RAM dbms.memory.heap.initial_size=3g dbms.memory.heap.max_size=3g dbms.memory.pagecache.size=2g
Currently used versions
Versions