# Import query runtime grows exponentially

**URL:** <https://community.neo4j.com/t/import-query-runtime-grows-exponentially/61585>\
**Category:** Cypher\
**Tags:** cypher, load-csv, import\
**Created:** [March 21, 2023, 4:43pm UTC](https://community.neo4j.com/t/import-query-runtime-grows-exponentially/61585 "2023-03-21T16:43:44Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![hamed.metalgear](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/hamed.metalgear/32/27543_2.png) [@hamed.metalgear](https://community.neo4j.com/u/hamed.metalgear)\
**Post date:** [March 21, 2023, 4:43pm UTC](https://community.neo4j.com/t/import-query-runtime-grows-exponentially/61585/1 "2023-03-21T16:43:44Z")

</div>

I am trying to bulk-import relationships from CSV files. The relationships are batched in groups of ~25,000 relationships per CSV file. A Cypher load query is used to read relationships from each CSV file. The query works as expected, though the runtime of the load query increases exponentially. Please see the following runtimes.

```auto
batch 1: 0.4 secs
batch 2: 0.9 secs
batch 3: 0.8 secs
...
batch 120: 3.9 secs
...
batch 200: 45.6 secs

```

The load query that is executed for each CSV file.

```auto
LOAD CSV WITH HEADERS FROM 'file:relationships_batch_1.csv' AS row
MATCH (x:Person {eid:row.xEid}), (y:Person {eid:row.yEid}) 
MERGE (x)-[r:`row.Type` {Price:toFloat(row.Price), Num:toInteger(row.Num)}]->(y)

```

where `row.Type` can have three possible values, hence not sure creating an index on that could improve performance.

For performance reasons, I define the following index on `Person`.

```auto
CREATE INDEX EidIndex
IF NOT EXISTS
FOR (p:Person) ON (p.eid)

```

---

<div class="post-metadata">

**Author:** ![lyonwj](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/lyonwj/32/27358_2.png) [@lyonwj](https://community.neo4j.com/u/lyonwj)\
**Post date:** [March 21, 2023, 5:16pm UTC](https://community.neo4j.com/t/import-query-runtime-grows-exponentially/61585/2 "2023-03-21T17:16:38Z")

</div>

What piece of the relationship pattern would you like to identify uniqueness of the relationship? Currently the combination of `row.Type`, `row.Price` and `row.Num` are used to identify uniqueness (because they are all specified in the `MERGE` statement and therefore every relationship needs to be checked and the relationship property values compared to the values in `row` for each row, which helps explain why you're seeing the slowdown.

If instead only the relationship type identifies uniqueness of the relationship you could try moving the relationship properties out of the `MERGE` and into a `SET`. Here's a version of that using `apoc.merge.relationship`:

```auto
LOAD CSV WITH HEADERS FROM 'file:relationships_batch_1.csv' AS row
MATCH (x:Person {eid:row.xEid})
MATCH (y:Person {eid:row.yEid}) 
CALL apoc.merge.relationship(x, row.Type,
  {},
  {price: toFloat(row.Price), num: toInteger(row.Num)},
  y,
  {}
)
YIELD rel

```

I used [`apoc.merge.relationship`](https://neo4j.com/labs/apoc/4.4/overview/apoc.merge/apoc.merge.relationship/) here because otherwise I don't think the value of `row.Type` is actually being picked up in your `MERGE` statement and rather your relationship type is always being set as the string value `"row.Type"`

---

<div class="post-metadata">

**Author:** ![hamed.metalgear](https://sea1.discourse-cdn.com/flex021/user_avatar/community.neo4j.com/hamed.metalgear/32/27543_2.png) [@hamed.metalgear](https://community.neo4j.com/u/hamed.metalgear)\
**Post date:** [March 21, 2023, 7:11pm UTC](https://community.neo4j.com/t/import-query-runtime-grows-exponentially/61585/3 "2023-03-21T19:11:03Z")

</div>

Thanks for the suggestion. I tried this, but unfortunately, it did not help. In fact, I reached ~10 sec per batch at batch 40, while previously I was at ~4 secs at batch 120.

Additionally, I need to use `Type`, `Price` and `Num` from my first example to identify the uniqueness of the relationship, which is not covered in your suggested solution.