Hi Alfred,
Thanks for clarification. I also have 2 questions:
1. For this query:
SELECT * FROM Model WHERE list = :1 AND list =:2 AND list=:3 AND string :=4
ORDER BY date DESC
will be enough this index?
- kind: Model
properties:
- name: list
- name: string
- name: date
direction:
On Fri, Jul 15, 2011 at 12:25 AM, Alexandru Farcaş
alex.far...@expert-group.biz wrote:
Hi Alfred,
Thanks for clarification. I also have 2 questions:
1. For this query:
SELECT * FROM Model WHERE list = :1 AND list =:2 AND list=:3 AND string :=4
ORDER BY date DESC
will be enough this
Yes, you are correct and those indexes will work. It's a trade of, composite
indexes 'pre-intersect' (at write time) properties while zigzag merge join
'post-intersects' properties (at read time). I left the ancestor in because
it is probably very 'selective' which has the potential to greatly
OMG... finally... zigzag merge join...
Any info on query performance
SELECT *
FROM Model
WHERE
list = :1 AND
list = :2 AND
list = :3
ORDER BY date DESC
with index
- kind: Model
properties:
- name: list
- name: date
or is it highly dependent on data distribution?
:-)
performance is data dependent.
Here is convoluted explanation of performance:
Sx = set of entities where list = :x
smallest_set = min(S1.size(), S2.size(), ...)
It works best when the intersection(S1, S2, S3,...) is large compared to the
smallest_set.
The pathological case is
I should point out the SDK is currently very insistent about it's
suggestions and believes that everything else is wrong (will throw
an NeedIndexError),
even though it may not be. We are working making the SDK smarter in this
regards, but until then you will have to test in production (you can
congratulations on this Alfred. I will try out a filter on multiple words in
the same list.
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To view this discussion on the web visit
exactly the same question ;)
On Tue, Jul 12, 2011 at 11:21 AM, Max thebb...@gmail.com wrote:
Great job!
May I know more about *t**he datastore now never requires an exploding
index*?
Does that mean we don't need to build exploding index or simply can't build
exploding index?
--
You
Hi,
It means that there are alternatives to using exploding indexes (i.e. they
are no longer required to execute a given query). You can still have them
(there are cases where they are useful, namely to optimize query speed over
write cost) and the SDK will still suggest them in many cases (as it
