"So at first, just run un-filtered query to see if your query works. Later
you can experiment with filters."
This query took 10 second
curl -XPOST "xxx/_search" -d'
{
"query": {
"has_child": {
"type": "person",
"query" : {
"match_all": {}
}
}
}
}
I will try to index with one shard, my performance goals are quite big, I
need an under a second query for "bool" filters (range term and terms), I
just need the count of the parents, nothing more.
Any tips?
'
On Thu, Jun 20, 2013 at 4:43 PM, Jörg Prante joergprante@gmail.com wrote:
has_child is always internally a filtered query.
Read the docs http://www.elasticsearch.org/**
guide/reference/query-dsl/has-**child-query/http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query/
"The has_child query works the same as the has_child filter, by
automatically wrapping the filter with a constant_score (when using the
default score type). "
Of course filters can be fast, but the price is high. They are fast if you
have enough memory and if all your doc terms and doc ids can be loaded into
memory. If not, they do not warn you, they are just becoming very slow,
because you just stress the JVM and the OS, and you have to trace the
numbers in the monitoring tools to find out if your heap is really the
problem, or if OS has a problem.
So at first, just run un-filtered query to see if your query works. Later
you can experiment with filters.
I can't tell if 8g is enough. Many people do not use large heaps, they
just add more nodes. 3 shards on 1 node are competing for the 8g. It means,
you have 2.66g for many millions of children. Did you calculate the size
per shard? So I assume with 1 shard per node you may be a little better for
has_child queries.
Jörg
Am 20.06.13 15:13, schrieb David MZ:
I was under the impression from reading that filtered query is the
fastest query, I only need counting, also search_type=count is suppose to
be better the _count
--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/**
topic/elasticsearch/Pr0G-**j10IaM/unsubscribehttps://groups.google.com/d/topic/elasticsearch/Pr0G-j10IaM/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@**googlegroups.comelasticsearch%2Bunsubscribe@googlegroups.com
.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.