Hi,
I was wondering whether this aggregation will work with parent documents
residing in different indexes than the children documents? Are there any
limitations with respect to shards? I remember parent-child relationships
have shard limitation as stated here: http://goo.gl/gU6Mcx.
In short,
Hi,
Is there an ES way to get a grand total of doc_count of all buckets of a
Terms aggregation? For instance to get 20 for the following:
{
"aggregations" : {
"genders" : {
"buckets" : [
{
"key" : "male",
"doc_count
HI Tanguy,
Is this library still maintained for the newer versions of ES, for example
1.4.0?
Thanks,
Ramin
On Wednesday, November 7, 2012 4:39:16 AM UTC-5, Tanguy wrote:
>
> Hi,
>
> Just to let you know - version 0.0.5 of this test library for JUnit &
> Elasticsearch has been released on OSS
I am still not expert an in ES but surely when not paging the process time
will be higher because more documents have to be brought back in the
response. However, depending on what kind of queries you perform, the
subsequent queries will be faster. I am thinking of *filter bool queries*
with ca
You really need to go over the query documentation first, there are plenty
of good examples and tutorials that will guide you and help you understand
your snippet.
I gather you understand the query part, the aggregation part (there are
lots of docs) shows the frequency (count) of touchdowns on
Hi,
I have two queries with identical nested aggregations using *min_doc_count* *=
0* option. The only difference is in the queries, first query is a
*match_all()* and the other a filtered query. The filtered query's
aggregations miss bucket keys here and there! I was expecting an exact
number
Hi,
I have several aggregations each of which have their own inner
aggregations. It seems that the 'min_document_doc' does not apply when
their containing aggregation is itself empty. I presumed that because both
level of aggregations use 'min_document_doc' there would be buckets for the
inner
Hi,
Consider the aggregation below:
"Sociodemographic_economic_characteristics": {
"terms": {
"field": "Sociodemographic_economic_characteristics",
"size": 0,
"min_doc_count": 0,
"order": {
"_term": "asc"
}
}
}
This is the result
What do you mean by " I have also required complete aggregate data", you
result is based on the type of the aggregation you use.
may be you can elaborate more.
Ramin
On Monday, November 3, 2014 11:33:55 PM UTC-5, Rajit Garg wrote:
>
> **I am Querying for getting aggregate data based on date_ran
s must clauses are only important during
> queries (not filters) since they contribute to the scoring for a document.
> The should clauses will improve the score for the documents that match.
>
> --
> Ivan
>
> On Mon, Nov 3, 2014 at 5:51 PM, kazoompa >
> wrote:
>
&g
query,
> any document returned MUST have a location of Germany. The valueType should
> clause is optional and actually pointless as a filter since it does not
> contribute to scoring.
>
> Can you explain what your query should be doing in terms of boolean logic?
>
> --
> Ivan
You will only see the difference when you have more complex queries that
combine MUST and SHOULD together. In your example you could have just
change MUST to SHOULD (i.e. used TERMS). By the definition, SHOULD is like
an OR and without a MUST clause it implies 'at least' one should match.
R
On
"type":
"study", "valueType": "text", "sentence": "jumbled mama", "location":
"france"}'
You can always have a look at the revised question and share your wisdom
with me :)
Cheers.
On Saturday, November 1,
Hi,
Below is my data and the two queries that I tested, first one failing and
the latter working. I start to believe that if one wants to combine several
SHOULD and MUST filters, the outer one must always be SHOULD. Is this a
correct assumption? In our application, we have much more complex sit
Hi,
Below is my data and the two queries that I tested, first one failing and
the latter working. I start to believe that if one wants to combine several
SHOULD and MUST filters, the outer one must always be SHOULD. Is this a
correct assumption? In our application, we have much more complex sit
Hi,
I would like to find the best efficient approach on performing manual
joins. A little background:
Our documents are updated quite frequently and they are rather large
(reason why we don't nest them). In addition, one document may be related
to two or more other documents (may be on differe
ocs
>
>
> Le 4 sept. 2014 à 23:01, kazoompa > a écrit :
>
> Hi,
>
> I would like to know whether I can perform a query and get not only the
> total hits but also the total document counts.
>
> Here is an example of one of my queries:
>
> {
> "fr
>
> Hi,
I would like to know whether I can perform a query and get not only the
total hits but also the total document counts.
Here is an example of one of my queries:
{
"from" : 0,
"size" : 30,
"query" : {
"filtered" : {
"query" : {
"match_all" : { }
},
"f
Hi,
I have the following ES setting defined in my YAML file:
http.enabled: false
discovery.zen.ping.multicast.enabled: false
index:
mappings:
_default_:
_timestamp:
enabled: true
store : true
analysis:
analyzer:
mica_index_analyzer:
type: custom
19 matches
Mail list logo
