Has_child performance - alternative implementation


(Moran B) #1

In the documentation it says that ALL parent IDs must be resident in
memory, the question is why.

Why can't the has_child run the query per shard, load into memory all of
the parent IDs that returned from the query and then use these to filter
the parent docs.
For some cases, the recall on the children would be much lower than the
parents, hence, no need for caching the parent-child relation at all.

Has this been tried? What are/were the considerations for implementing this
as it is?

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/6d13b8fe-6d00-4090-b15d-5484729d6810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Drew) #2

I'm interested to find this out too.

On Jun 25, 2014, at 4:45 AM, Moran B moran.benisty@gmail.com wrote:

In the documentation it says that ALL parent IDs must be resident in memory, the question is why.

Why can't the has_child run the query per shard, load into memory all of the parent IDs that returned from the query and then use these to filter the parent docs.
For some cases, the recall on the children would be much lower than the parents, hence, no need for caching the parent-child relation at all.

Has this been tried? What are/were the considerations for implementing this as it is?

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/6d13b8fe-6d00-4090-b15d-5484729d6810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3FD5D7FE-9120-4BE7-A340-3BA70FE9449F%40venarc.com.
For more options, visit https://groups.google.com/d/optout.


(system) #3