I meant: with an index you the fast lookup but no pentalty with an constraint you have the uniqueness guarantee via a lock and check against the constraint on write, both of which cost.
But I ask if that can be alleviated. Could you test it in 3.0.2 if it performs better? Michael > Am 27.05.2016 um 00:29 schrieb Eric Fulton <eful...@blueorigin.com>: > > I'm sorry, I'm not sure exactly what you mean by query scan. I haven't > changed any of the queries from before the addition of the uniqueness > constraint. I'm still doing the same "MERGE ..." query (like above, but with > parameters, as you pointed out). Do you mean that, or something else? > > Thanks! > Eric > > -- > 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. -- 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.
