I would definitely expect there to be additional overhead now because before the write can happen an index lookup against uid now needs to happen. that has to take some time. I also wonder if you are getting some lock contention doing this multithreaded.
> On May 25, 2016, at 6:10 PM, Eric Fulton <[email protected]> wrote: > > > When I add data to the database, I use a merge something like this: > MERGE (n:Thing { uid : <the uid>}) ON CREATE SET n.prop1 = blah1, n.prop2 = > blah2 ... > > Since I'm working in a multi-threaded environment, it's possible to have the > same node written twice and I've seen many instances where duplicate nodes > are created. SO > I have an index on the uid. > > CREATE CONSTRAINT ON (n:Thing) ASSERT n.uid IS UNIQUE > > > Before creating the index, those merges were taking 1-50ms, now they take > 20-300ms. Other operations like adding relationships seem to be taking quite > a bit longer too. > > -- > 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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
