Are you also adding/modifying documents while searching with has_parent or
has_child query?
In that it makes sense to enable global ordinals loading on the _parent
field:
http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/parent-child-performance.html#_global_ordinals_and_latency
Th
tering works fine - so this should mean that the percolator
>> **is** in the index and is accessible via the alias.
>>
>> So again, I'm not sure why percolator filtering isn't working - as I've
>> said, I assume I'm misunderstanding/doing something wrong, bu
The index that the percolator query is in is named: '
activities-20150107-162224', but your are percolating on the `activities`
index. I think in the activities index there is no `doc_type` field defined
in the `.percolator` type, so that is why there are no matches. If you you
use activities* as i
nything that even implies that `from`
> is not supported for a scroll search, except of course when
> `search_type=scan`.
>
> I would love to get support for that back into the product.
>
> --g
>
>
>
> On Wednesday, January 21, 2015 at 2:57:29 AM UTC-6, Martijn v Groningen
Hi Gordon,
This `from` is kind of ignored for scroll search. I don't remember why that
was the case, but it seems to me that scroll search can/should take into
account the `from` option during the first scroll search request.
Martijn
On 20 January 2015 at 23:33, Gordon Tillman wrote:
> Greetin
ts of each array, and then for each doc_id, pull out
>> the relevant fields to return to the user. So definitely more work (and a
>> lot more memory), but I'm not sure if this would result in the 30x increase
>> in runtime we're seeing. (And actually, for the
ess memory. But I
> understand it needs to be able to handle more general cases.)
>
> Is this at all close to how it works?
>
> On Tuesday, January 6, 2015 11:20:08 PM UTC-8, Martijn v Groningen wrote:
>>
>> Hi Michael,
>>
>> In general the more buckets being
Hi Michael,
In general the more buckets being returned by the parent aggregator the
top_hits is nested in, the more work the top_hits agg needs to do, but I
didn't come across performance issues with `size` on terms agg being set to
50 and the time it takes to execute increasing 30 times when top_
t of things via logstash almost continuously.
>
> Jilles
>
>
>
> On Thursday, November 27, 2014 4:06:21 PM UTC+1, Martijn v Groningen wrote:
>>
>> This looks like a mapping issue to me (not 100% sure). A document that is
>> in the translog has a string field (with
This looks like a mapping issue to me (not 100% sure). A document that is
in the translog has a string field (with value: 'finished'), but it is
mapped as a number field (long, integer, double, etc.) in the mapping. This
causes the number format exception that you're seeing in your logs when
that d
In the case of percolator queries are indexed before actual data is
evaluated, which triggers the automatic addition of fields in mappings.
Most of the times this is ok, but there are a number of queries that
require the field mapping to exist before the percolator query is indexed.
Because of thi
cluster (8 rxlarge, etc etc) went down
> after 2 days updating paren-child relations.
> Index volume is tiny, but the number of child documents updated is huge.
>
> Thank you.
>
> Vlad
>
>
> On Tuesday, October 21, 2014 4:38:55 PM UTC+2, Martijn v Groningen wrote:
>>
>
t;de"}'
>>>
>>> #Index child document:
>>> curl -XPUT 'http://localhost:9200/test/metric/1?parent=1' -d
>>> '{"count":1}'
>>> #Update child document:
>>> curl -XPOST 'http://localhost:9200/test/metric/1/_updat
> #Update child document:
> curl -XPOST 'http://localhost:9200/test/metric/1/_update?parent=1' -d
> '{"script":"ctx._source.count+=ct", "params":{"ct":1}}'
> #Query with benchmark query, it should return 2
> curl -XGET localho
Hi Vlad,
What you're describing shouldn't happen. The child docs should get
detached. I think this is a bug.
Let me verify and get back to you.
Martijn
On 21 October 2014 13:26, Vlad Vlaskin wrote:
> After some experiments I believe I found the cause of the discrepancy
> problem:
>
> *ElasticS
Hi Vlad,
I see that the doc_count is also different between the requests. Is the
actual bucket key also different between A and B?
Martijn
On 21 October 2014 03:18, Vlad Vlaskin wrote:
> Dear ES group,
> we've been using ES in production for a while and test eagerly all
> new-coming features s
How many index / delete or update requests are you bundeling in a single
bulk api call?
On 9 October 2014 10:19, Bernhard Berger
wrote:
> My application write bulk updates the whole time in an Elasticsearch index
> (index size: ~200,000 docs, 35 MB, shards: 3*2; segment count ~35).
> My cluster
which clearly contains
> a "_parent" field, when I'm doing a "must_not" "has_parent" filter? That
> should never be possible.
>
> On 2 October 2014 20:54, Martijn v Groningen <
> martijn.v.gronin...@gmail.com> wrote:
>
>> Can you sha
Can you share a reproduction of the mismatches you're experiencing? (in a
gist or something like that, so that I can see on what data you're running
these queries)
The has_parent query in a must clause should return all child documents
with a parent and a has_parent in must_not should return all c
You need to wrap the has_parent query in the query part of the filtered
query:
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-filtered-query.html#query-dsl-filtered-query
I don't see how this query could have worked in 0.90.5, since the format is
incorrect, but if
Hi,
In that case you would need to wrap a terms agg in a nested aggregation
(with the desired path) and a top_hits inside that terms aggregation.
Unfortunately the top_hits aggregation doesn't yet work inside a nested
aggregation. However work is being done that will add this support:
https://gith
yen wrote:
> Thanks for the response, Martijn! We'll consider upgrading, but it'd be
> great to root cause the issue.
>
> On Tuesday, September 9, 2014 12:03:57 AM UTC-7, Martijn v Groningen wrote:
>>
>> Patrick: I have never seen this, but this means the openjdk o
Patrick: I have never seen this, but this means the openjdk on FreeBSD
doesn't support cpu sampling of threads. Not sure, but maybe you can try
with an Oracle jdk/jre? Otherwise jstack should be used on order to figure
out on what threads of ES get stuck on.
Hieu: This doesn't look like the issue
s thread.
> All I know is what I've posted in my first message.
>
> I've restarted ES, and currently I've no stuck thread to investigate. In
> the mean time, you can teach me how I should use jstack, so next time it
> happens I'll be ready.
>
> On 2
Hi Patrick,
Did you see the same stuck thread via jstack or the hot thread api that
Martin reported? This can only happen if scan search was enabled (by
setting search_type=scan in a search request)
If that isn't the case then something else is maybe stuck.
Martijn
On 29 August 2014 09:58, Patr
t; }
>> }
>> }
>>
>> The result is:
>>
>>
>>- aggregations: {
>> - replies: {
>> - buckets: [
>> - {
>>- key: 5643
>>- doc_count: 1
>>- top_s
Hi Dan,
The buckets of there replies terms agg are sorted by default by their doc
count, but the hits inside topChildren agg are sorted by default by the
score of the query.
I think if you sort the replies buckets by highest score you get what you
want. In order to do this you need to define a max
Do the amount of registered percolate queries also increase?
On 15 July 2014 12:02, Seungjin Lee wrote:
>
>
> hi all,
>
> we use elasticsearch with storm, continuously making percolation request.
>
> as you see above, percolator throughput decreases as time passes.
>
> but we are not seeing a
Hi Stephan,
The bug has been fixed, can you try out a new build?
Martijn
On 30 May 2014 09:45, Martijn v Groningen
wrote:
> This is indeed a bug, thanks for sharing it! This should be easy to fix.
>
>
> On 27 May 2014 11:35, wrote:
>
>> Hello,
>> I tried the n
This is indeed a bug, thanks for sharing it! This should be easy to fix.
On 27 May 2014 11:35, wrote:
> Hello,
> I tried the new top_hots aggregation and made it work on denormalized data.
>
> However, when I tries to add a filter I ran into the following exception:
>
> [2014-05-27 11:32:12,869
0:9200/idx-1/docs/123/_percolate -d '{
> "filter": {
> "term": {
> "account_id": 1
> }
> }
> }'
> ```
>
> Thanks again.
>
> On Tuesday, May 20, 2014 2:18:02 AM UTC-7, Martijn v Groningen wrote:
>
>>
Is the `location` field an object field or a nested field? The nested
filter should only be used if in the mapping you have specified the
`location` field to be nested. If that isn't the case you can just remove
the nested filter from you query.
On 20 May 2014 09:24, razafinr wrote:
> Hi!
>
> I
1. Yes, the routing will be taken into during adding the percolator query.
2. At the moment only the routing will be taken into account, the filter
will not be taken into account.
I opened issue percolator against an alias with a filter:
https://github.com/elasticsearch/elasticsearch/issues/6241
;6b256fd1-cd04-4e3c-8f38-aaa87ac2220d"]}}}
> },
>
>
> {
> "_index" : "my_idx",
> "_type" : ".percolator",
> "_id" : "inFilterQ",
> "_score" : 1.0, "_source" :
&
You would only get this error if the "doc" part in the request body is
missing of the percolate request. Can you share the entire percolate
request?
On 6 May 2014 18:54, razafinr wrote:
> I am using elasticsearch 1.1.
>
> Normally in this version, percolator on nested documents should work.
>
>
Hi,
Can you also share the document being percolated? I would expect the query
to match if gasoline occurs in it and 'product' is equal to 'some_product'.
You may have ran into a big regarding to the percolator and mappings:
https://github.com/elasticsearch/elasticsearch/pull/5776
That has been f
> such behavior of elasticsearch?
>>>>
>>>> Our another question is if there is any way we could put the UUID list
>>>> as a list into a query that is working with the percolator, like what we
>>>> can do for inQuery or inFilter. We tried register an inQu
Hi,
Can you share the stored percolator queries and the percolate request that
you were initially trying with, but didn't work?\
Martijn
On 2 May 2014 11:14, JGL wrote:
> Can anybody help plz?
>
> --
> You received this message because you are subscribed to the Google Groups
> "elasticsearch"
This is a bug and has been fixed. Can you try using the latest 0.90.x
release or maybe upgrade to the latest 1.0.x release?
On 20 March 2014 00:02, Riyaz wrote:
> Hi,
>
> I am using elasticsearch v0.90.5 and trying to set QueryName (_name) for a
> has_child query as described here:
> http://www
5 percolator queries isn't a big deal. I was thinking order magnitude of
100k percolator queries and up.
On 11 March 2014 18:02, Lee Hinman wrote:
> Hi Dunaeth,
>
> Can you attach the output of `curl 'localhost:9200/_nodes/stats?all'`, I
> would like to compare the current breaker estimation an
:56 UTC+1, Dunaeth a écrit :
>>>
>>> I'm asking our hoster to monitor these metrics and to avoid any
>>> confusion, the breaker indice size actually monitor the
>>> fielddata_breaker.estimated_size_in_bytes from the /_nodes/stats
>>> endpoint. Thanks
Yes, the breaker indices size does grow quickly. Can you share the same
graphs for jvm heap used and field data size?
On 10 March 2014 15:16, Dunaeth wrote:
> Hi,
>
> In order to be more precise, here are the graphs of the metrics we monitor
> since we've had the fielddata breaker issue :
>
>
>
Hi James,
The `type` top level field is used during registering the query to point to
a mapping. This allows ES to properly resolve field names, so for example
when indexing a query with a range query/filter it can get properly
resolved to a numeric range query if a field is of the type number.
T
ng Oracle Java 7u45
>
>
> On Tuesday, March 4, 2014 1:05:13 AM UTC-8, Martijn v Groningen wrote:
>
>> I see that you a lot of time is spend on just measuring how memory the
>> query takes in memory and not parsing the query. I think this slowness
>> might be jvm versi
ow at all.
> 2. A regular document takes ~75ms.
> 3. https://gist.github.com/julesbravo/9337810
>
> It looks like it's definitely CPU bound.
>
>
> On Monday, March 3, 2014 3:40:05 PM UTC-8, Martijn v Groningen wrote:
>
>> On top of just indexing a document, the top le
On top of just indexing a document, the top level 'query' field part gets
parsed into a internal Lucene query. However I don't see why this should
take a long time.
Some questions:
Are you running low on jvm memory?
How long does it take to index a regular document?
Can you run the hot threads api
The settings for the fielddata breaker are global. Any index can be
affected by it, new indices and already existing indices.
For example when new data is added to an existing index, new field data
entries may be created and if there isn't sufficient memory because of
other field data entries for
Did you look into the nested type[1] and nested query[2]? I think that
would be a solution for you.
1:
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-nested-type.html
2:
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl-nested-query.html
Hi,
This particular issue has been fixed via another issue:
https://github.com/elasticsearch/elasticsearch/issues/4703
The 4703 issue fix will be included 0.90.11 and 1.0-rc2.
Martijn
On 29 January 2014 05:32, seallison wrote:
> I'm getting a NullPointerException in Elasticsearch 0.90.10 w
Hi Paul,
The mapping and query that you're sharing make sense and should work. I
verified that with a small recreation:
https://gist.github.com/martijnvg/8639841
What I think you're running into is that a document of type 'myParent'
doesn't have the field `weight`. Can you check if that is the ca
Sorry for responding so late... something like this is possible:
https://gist.github.com/martijnvg/8511859
By using `score_type=max` and wrapping the inner query in a `constant_score
query`, the score represents the number of child docs that match with a
parent. Then by using the `min_score` featu
; forward to testing your fix, hopefully in 0.90.11 :)
>
> Regards,
> -- JB.L
>
>
>
> 2014/1/14 Martijn v Groningen
>
>> So this is related to:
>> https://github.com/elasticsearch/elasticsearch/issues/4703
>>
>>
>> On 14 January 2014 23:23, Martijn
So this is related to:
https://github.com/elasticsearch/elasticsearch/issues/4703
On 14 January 2014 23:23, Martijn v Groningen wrote:
> I'm a bit confused the first query with has_parent doesn't return hits,
> but the second does according to your gist or I'm I misreading
made on my ES 0.90.6 node, as well as a link to the Java code
>> responsible for the calls:
>> https://gist.github.com/jblievremont/8331460
>>
>> Please note that the issue appears only when combining scan/scroll with
>> has_parent filter, as it seems to work using a has_parent que
Hi Jean,
Can you share how you execute the scan request with the has_parent filter?
(via a gist or something like that)
Martijn
On 8 January 2014 15:17, Jean-Baptiste Lièvremont <
jean-baptiste.lievrem...@sonarsource.com> wrote:
> Hi folks,
>
> I use a parent/child mapping configuration which
55 matches
Mail list logo
