How long will a query with two "contains" tests take to execute on the appengine datastore?
I have two sets of thirty or forty IDs, set A and set B. I have a kind of entity that has a field idA (an id that might be in set A) and a field idB (an id that might be in set B). I want to find all of the entities with idA in set A and idB in set B.
I could perform a query with filters like "A.contains(idA) && B.contains(idB)," but I worry about how much time this would take. With 30 ids in A, a naive implementation might take 30 comparisons per non-matching entity in the datastore. Or maybe the datastore sorts A and B before it goes looking, and will only take 4 or 5 comparisons per entity in the datastore. Or, maybe there's something that google figured out that I haven't, that could quickly skip over entities.
Basically, I'm trying to figure out what the index for such a query looks like, and if this is a terrible kind of query to run. Maybe it orders by idA, then by idB, and sorts A and B before the query is actually executed?
Main question: with 30-40 elements in A and B, will a query with filters "A.contains(idA) && B.contains(idB)" execute in a reasonable amount of time, or should I try to get this information another way?
You are limited to a list of at most thirty items. So this will not currently run on App Egnine, see the Query Filters section.
The contains() operator also performs multiple queries, one for each item in the provided list value where all other filters are the same and the contains() filter is replaced with an equal-to filter. The results are merged, in the order of the items in the list. If a query has more than 1 contains() filter, the query is performed as multiple queries, one for each combination of values in the contains() filters.
A single query containing != or contains() operators is limited to 30 sub-queries.
App Engine will expand your query into 30 * 40 = 1200 queries for individual combinations of idA and idB - or at least, it would, if it weren't limited to 30 sub-queries. Obviously, this isn't going to be very efficient.
Alternatives depend on the structure of your datastore. If you tell us what you're trying to achieve, we may be able to suggest alternatives that don't require so many queries.