In an application that I am currently working on, we need to ensure uniqueness with respect to the tuple of three properties in a specific kind. As such when creating a new entity, we need to ensure that no entity of that kind with the given tuple exists.
My naïve approach to this problem, was to create a simple query that filters on equality based on the three fields. If an entity with the given fields was found, the operation would abort, otherwise a new entity with those fields and other related data would be inserted. However, when trying to insert many entities in parallel, transaction contention would arise.
However, as soon as I added a composite index of those three properties, no contention occurs. I changed nothing in the code, I merely added a composite index for those fields.
I have been digging through all the documentation and searched around for anyone who has had a similar issue, but nobody has ever mentioned this "workaround".
Have I missed something? Perhaps discovered something? Or this is expected behavior; are the built-in indices not enough?
The main document you'd want to look at is https://cloud.google.com/datastore/docs/concepts/optimize-indexes .
In your case it looks like your merge join ends up locking a number of rows while looking for no-match. However, with the composite index you are only looking up the index entry needed for your query. Thus there is less contention with the composite index vs using a merge join for the query.