Prevent some words from being "stopped"

Elastic Stack Elasticsearch
1

Is there any way of "marking" a word not to be filtered out by the stop
filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks" a
keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two words
belonging to the standard stop words list of their language. Say, for a
spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a custom
stopwords list with "tenga" not in it, and I just did that, but it would be
"cheaper" instead of reespecifying the whole set, to say "exception"s:
["tenga"]

On a sidenote: where can I find the default list that elasticsearch uses
when specifying ["es"] as stopwords???

--
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.

2

you might want to look at the cutoff_frequency that was added to the
match_query
(Elasticsearch Platform — Find real-time answers at scale | Elastic) It
might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the stop
filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks" a
keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two words
belonging to the standard stop words list of their language. Say, for a
spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a custom
stopwords list with "tenga" not in it, and I just did that, but it would be
"cheaper" instead of reespecifying the whole set, to say "exception"s:
["tenga"]

On a sidenote: where can I find the default list that elasticsearch uses
when specifying ["es"] as stopwords???

--
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.

3

I didn't know about that feature. is it a new thing?

anyway, I think other considerations regarding how we build the query
before hitting the search server may prevent us for taking that road. but I
gotta take a deeper look into it.

as how we use stopwords, it's pretty standard:

"index_name": {
"index": {
...
...
"analysis": {
"analyzer": {
"default_index": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop", ...]
},
"default_search": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop", ...]
},
},
"filter": {
...
"my_stop":{
"type": "stop",
"stopwords": ["es"]
},
...
}
}
}
},

do you happen to know where the default stopwords are defined?

On Sunday, May 19, 2013 5:38:13 PM UTC-4, simonw wrote:

you might want to look at the cutoff_frequency that was added to the
match_query (
Elasticsearch Platform — Find real-time answers at scale | Elastic) It
might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the stop
filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks" a
keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two
words belonging to the standard stop words list of their language. Say, for
a spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a
custom stopwords list with "tenga" not in it, and I just did that, but it
would be "cheaper" instead of reespecifying the whole set, to say
"exception"s: ["tenga"]

On a sidenote: where can I find the default list that elasticsearch uses
when specifying ["es"] as stopwords???

--
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.

4

On Monday, May 20, 2013 7:58:53 AM UTC+2, JoeZ99 wrote:

I didn't know about that feature. is it a new thing?

yes it's pretty new. 0.90 only.

anyway, I think other considerations regarding how we build the query
before hitting the search server may prevent us for taking that road. but I
gotta take a deeper look into it.

this feature makes your live easier not harder so going don't that road
should be downhill. It essentially means you don't filter stopwords anymore
and gain the ability to run stopword only searches fast as well. stuff like
"to be or not to be" etc.

as how we use stopwords, it's pretty standard:

ok so why don't you just modify the stopword list if a customer asks for
it? I assume you have an index per customer?

simon

"index_name": {
"index": {
...
...
"analysis": {
"analyzer": {
"default_index": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop", ...]
},
"default_search": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop", ...]
},
},
"filter": {
...
"my_stop":{
"type": "stop",
"stopwords": ["es"]
},
...
}
}
}
},

do you happen to know where the default stopwords are defined?

On Sunday, May 19, 2013 5:38:13 PM UTC-4, simonw wrote:

you might want to look at the cutoff_frequency that was added to the
match_query (
Elasticsearch Platform — Find real-time answers at scale | Elastic) It
might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the stop
filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks" a
keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two
words belonging to the standard stop words list of their language. Say, for
a spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a
custom stopwords list with "tenga" not in it, and I just did that, but it
would be "cheaper" instead of reespecifying the whole set, to say
"exception"s: ["tenga"]

On a sidenote: where can I find the default list that elasticsearch uses
when specifying ["es"] as stopwords???

--
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.

5

On Monday, May 20, 2013 2:53:02 PM UTC-4, simonw wrote:

On Monday, May 20, 2013 7:58:53 AM UTC+2, JoeZ99 wrote:

I didn't know about that feature. is it a new thing?

yes it's pretty new. 0.90 only.

anyway, I think other considerations regarding how we build the query
before hitting the search server may prevent us for taking that road. but I
gotta take a deeper look into it.

this feature makes your live easier not harder so going don't that road
should be downhill. It essentially means you don't filter stopwords anymore
and gain the ability to run stopword only searches fast as well. stuff like
"to be or not to be" etc.

Well, I'm definitely going to check that out . Can I do that "cutoff"
thing in a query that is not a "match query". I understood I couldn't
(that's why I'm not sure I can use it, because I'm not sure I can use match
query altogether).

as how we use stopwords, it's pretty standard:

ok so why don't you just modify the stopword list if a customer asks for
it? I assume you have an index per customer?

simon

Of course I've got an index per customer, and of course that's what I'm
doing now (that's why I want to know where the "standard" stopwords are
defined, so I can copy/paste them without a few ones the customer doesn't
want), replacing the entire stopwords collection for a custom-made one. I
just thought it would be easiest to define the two stopwords that
"shouldn't be there" than redeclare the whole stopwords bunch.

"index_name": {
"index": {
...
...
"analysis": {
"analyzer": {
"default_index": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
"default_search": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
},
"filter": {
...
"my_stop":{
"type": "stop",
"stopwords": ["es"]
},
...
}
}
}
},

do you happen to know where the default stopwords are defined?

On Sunday, May 19, 2013 5:38:13 PM UTC-4, simonw wrote:

you might want to look at the cutoff_frequency that was added to the
match_query (
Elasticsearch Platform — Find real-time answers at scale | Elastic) It
might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the stop
filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks" a
keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two
words belonging to the standard stop words list of their language. Say, for
a spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a
custom stopwords list with "tenga" not in it, and I just did that, but it
would be "cheaper" instead of reespecifying the whole set, to say
"exception"s: ["tenga"]

On a sidenote: where can I find the default list that elasticsearch
uses when specifying ["es"] as stopwords???

--
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.

6

On Tuesday, May 21, 2013 4:12:14 PM UTC+2, JoeZ99 wrote:

On Monday, May 20, 2013 2:53:02 PM UTC-4, simonw wrote:

On Monday, May 20, 2013 7:58:53 AM UTC+2, JoeZ99 wrote:

I didn't know about that feature. is it a new thing?

yes it's pretty new. 0.90 only.

anyway, I think other considerations regarding how we build the query
before hitting the search server may prevent us for taking that road. but I
gotta take a deeper look into it.

this feature makes your live easier not harder so going don't that road
should be downhill. It essentially means you don't filter stopwords anymore
and gain the ability to run stopword only searches fast as well. stuff like
"to be or not to be" etc.

Well, I'm definitely going to check that out . Can I do that "cutoff"
thing in a query that is not a "match query". I understood I couldn't
(that's why I'm not sure I can use it, because I'm not sure I can use match
query altogether).

yes there is a common_terms query but apparently I never finished the
documentation for this one. Hmm it's still sitting in my local clone. Lemme
finish the documentation and update you once it's there. what query are you
using right now?

as how we use stopwords, it's pretty standard:

ok so why don't you just modify the stopword list if a customer asks for
it? I assume you have an index per customer?

simon

Of course I've got an index per customer, and of course that's what I'm
doing now (that's why I want to know where the "standard" stopwords are
defined, so I can copy/paste them without a few ones the customer doesn't
want), replacing the entire stopwords collection for a custom-made one. I
just thought it would be easiest to define the two stopwords that
"shouldn't be there" than redeclare the whole stopwords bunch.

it seems like stop filter could support keyword attribute as well but I am
not sure if that is really what we should do. seems like a unique
requirement. usually you wanna specify a custom list not an exclusion set.

simon

"index_name": {
"index": {
...
...
"analysis": {
"analyzer": {
"default_index": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
"default_search": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
},
"filter": {
...
"my_stop":{
"type": "stop",
"stopwords": ["es"]
},
...
}
}
}
},

do you happen to know where the default stopwords are defined?

On Sunday, May 19, 2013 5:38:13 PM UTC-4, simonw wrote:

you might want to look at the cutoff_frequency that was added to the
match_query (
Elasticsearch Platform — Find real-time answers at scale | Elastic)
It might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the
stop filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks" a
keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two
words belonging to the standard stop words list of their language. Say, for
a spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a
custom stopwords list with "tenga" not in it, and I just did that, but it
would be "cheaper" instead of reespecifying the whole set, to say
"exception"s: ["tenga"]

On a sidenote: where can I find the default list that elasticsearch
uses when specifying ["es"] as stopwords???

--
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.

7

On Tuesday, May 21, 2013 9:40:20 PM UTC+2, simonw wrote:

On Tuesday, May 21, 2013 4:12:14 PM UTC+2, JoeZ99 wrote:

On Monday, May 20, 2013 2:53:02 PM UTC-4, simonw wrote:

On Monday, May 20, 2013 7:58:53 AM UTC+2, JoeZ99 wrote:

I didn't know about that feature. is it a new thing?

yes it's pretty new. 0.90 only.

anyway, I think other considerations regarding how we build the query
before hitting the search server may prevent us for taking that road. but I
gotta take a deeper look into it.

this feature makes your live easier not harder so going don't that road
should be downhill. It essentially means you don't filter stopwords anymore
and gain the ability to run stopword only searches fast as well. stuff like
"to be or not to be" etc.

Well, I'm definitely going to check that out . Can I do that "cutoff"
thing in a query that is not a "match query". I understood I couldn't
(that's why I'm not sure I can use it, because I'm not sure I can use match
query altogether).

yes there is a common_terms query but apparently I never finished the
documentation for this one. Hmm it's still sitting in my local clone. Lemme
finish the documentation and update you once it's there. what query are you
using right now?

here you go:

simon

as how we use stopwords, it's pretty standard:

ok so why don't you just modify the stopword list if a customer asks for
it? I assume you have an index per customer?

simon

Of course I've got an index per customer, and of course that's what I'm
doing now (that's why I want to know where the "standard" stopwords are
defined, so I can copy/paste them without a few ones the customer doesn't
want), replacing the entire stopwords collection for a custom-made one. I
just thought it would be easiest to define the two stopwords that
"shouldn't be there" than redeclare the whole stopwords bunch.

it seems like stop filter could support keyword attribute as well but I am
not sure if that is really what we should do. seems like a unique
requirement. usually you wanna specify a custom list not an exclusion set.

simon

"index_name": {
"index": {
...
...
"analysis": {
"analyzer": {
"default_index": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
"default_search": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
},
"filter": {
...
"my_stop":{
"type": "stop",
"stopwords": ["es"]
},
...
}
}
}
},

do you happen to know where the default stopwords are defined?

On Sunday, May 19, 2013 5:38:13 PM UTC-4, simonw wrote:

you might want to look at the cutoff_frequency that was added to the
match_query (
Elasticsearch Platform — Find real-time answers at scale | Elastic)
It might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the
stop filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks"
a keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two
words belonging to the standard stop words list of their language. Say, for
a spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a
custom stopwords list with "tenga" not in it, and I just did that, but it
would be "cheaper" instead of reespecifying the whole set, to say
"exception"s: ["tenga"]

On a sidenote: where can I find the default list that elasticsearch
uses when specifying ["es"] as stopwords???

--
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.

8

On Tuesday, May 21, 2013 3:40:20 PM UTC-4, simonw wrote:

On Tuesday, May 21, 2013 4:12:14 PM UTC+2, JoeZ99 wrote:

On Monday, May 20, 2013 2:53:02 PM UTC-4, simonw wrote:

On Monday, May 20, 2013 7:58:53 AM UTC+2, JoeZ99 wrote:

I didn't know about that feature. is it a new thing?

yes it's pretty new. 0.90 only.

anyway, I think other considerations regarding how we build the query
before hitting the search server may prevent us for taking that road. but I
gotta take a deeper look into it.

this feature makes your live easier not harder so going don't that road
should be downhill. It essentially means you don't filter stopwords anymore
and gain the ability to run stopword only searches fast as well. stuff like
"to be or not to be" etc.

Well, I'm definitely going to check that out . Can I do that "cutoff"
thing in a query that is not a "match query". I understood I couldn't
(that's why I'm not sure I can use it, because I'm not sure I can use match
query altogether).

yes there is a common_terms query but apparently I never finished the
documentation for this one. Hmm it's still sitting in my local clone. Lemme
finish the documentation and update you once it's there. what query are you
using right now?

I'm using either text, phrase_prefix or, in some cases, fuzzy

as how we use stopwords, it's pretty standard:

ok so why don't you just modify the stopword list if a customer asks for
it? I assume you have an index per customer?

simon

Of course I've got an index per customer, and of course that's what I'm
doing now (that's why I want to know where the "standard" stopwords are
defined, so I can copy/paste them without a few ones the customer doesn't
want), replacing the entire stopwords collection for a custom-made one. I
just thought it would be easiest to define the two stopwords that
"shouldn't be there" than redeclare the whole stopwords bunch.

it seems like stop filter could support keyword attribute as well but I am
not sure if that is really what we should do. seems like a unique
requirement. usually you wanna specify a custom list not an exclusion set.

simon

"index_name": {
"index": {
...
...
"analysis": {
"analyzer": {
"default_index": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
"default_search": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
},
"filter": {
...
"my_stop":{
"type": "stop",
"stopwords": ["es"]
},
...
}
}
}
},

do you happen to know where the default stopwords are defined?

On Sunday, May 19, 2013 5:38:13 PM UTC-4, simonw wrote:

you might want to look at the cutoff_frequency that was added to the
match_query (
Elasticsearch Platform — Find real-time answers at scale | Elastic)
It might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the
stop filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks"
a keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two
words belonging to the standard stop words list of their language. Say, for
a spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a
custom stopwords list with "tenga" not in it, and I just did that, but it
would be "cheaper" instead of reespecifying the whole set, to say
"exception"s: ["tenga"]

On a sidenote: where can I find the default list that elasticsearch
uses when specifying ["es"] as stopwords???

--
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.

9

thanks!!

On Wednesday, May 22, 2013 11:43:34 AM UTC-4, simonw wrote:

On Tuesday, May 21, 2013 9:40:20 PM UTC+2, simonw wrote:

On Tuesday, May 21, 2013 4:12:14 PM UTC+2, JoeZ99 wrote:

On Monday, May 20, 2013 2:53:02 PM UTC-4, simonw wrote:

On Monday, May 20, 2013 7:58:53 AM UTC+2, JoeZ99 wrote:

I didn't know about that feature. is it a new thing?

yes it's pretty new. 0.90 only.

anyway, I think other considerations regarding how we build the query
before hitting the search server may prevent us for taking that road. but I
gotta take a deeper look into it.

this feature makes your live easier not harder so going don't that road
should be downhill. It essentially means you don't filter stopwords anymore
and gain the ability to run stopword only searches fast as well. stuff like
"to be or not to be" etc.

Well, I'm definitely going to check that out . Can I do that "cutoff"
thing in a query that is not a "match query". I understood I couldn't
(that's why I'm not sure I can use it, because I'm not sure I can use match
query altogether).

yes there is a common_terms query but apparently I never finished the
documentation for this one. Hmm it's still sitting in my local clone. Lemme
finish the documentation and update you once it's there. what query are you
using right now?

here you go:
Elasticsearch Platform — Find real-time answers at scale | Elastic

simon

as how we use stopwords, it's pretty standard:

ok so why don't you just modify the stopword list if a customer asks
for it? I assume you have an index per customer?

simon

Of course I've got an index per customer, and of course that's what I'm
doing now (that's why I want to know where the "standard" stopwords are
defined, so I can copy/paste them without a few ones the customer doesn't
want), replacing the entire stopwords collection for a custom-made one. I
just thought it would be easiest to define the two stopwords that
"shouldn't be there" than redeclare the whole stopwords bunch.

it seems like stop filter could support keyword attribute as well but I
am not sure if that is really what we should do. seems like a unique
requirement. usually you wanna specify a custom list not an exclusion set.

simon

"index_name": {
"index": {
...
...
"analysis": {
"analyzer": {
"default_index": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
"default_search": {
"tokenizer": "standard",
"filter": ["standard", "lowercase", "my_stop",
...]
},
},
"filter": {
...
"my_stop":{
"type": "stop",
"stopwords": ["es"]
},
...
}
}
}
},

do you happen to know where the default stopwords are defined?

On Sunday, May 19, 2013 5:38:13 PM UTC-4, simonw wrote:

you might want to look at the cutoff_frequency that was added to
the match_query (
Elasticsearch Platform — Find real-time answers at scale | Elastic)
It might enable you to not filter stopwords at all. Another option is to
create a stopword list per customer and add it to the mapping yourself, how
are you creating your stopword filters right now?

simon

On Sunday, May 19, 2013 10:55:06 PM UTC+2, JoeZ99 wrote:

Is there any way of "marking" a word not to be filtered out by the
stop filter, even if it's on the stop words??

I'm looking for something like "keywordmarker" filter, which "marks"
a keyword not to be stemmed afterwards.

Use case. Some customers have a special meaning from just one or two
words belonging to the standard stop words list of their language. Say, for
a spanish customer, he want the word "tenga" to be searchable even if it
belongs to the "es" expanded stopwords.

I know I could just override the whole stopwords set, and provide a
custom stopwords list with "tenga" not in it, and I just did that, but it
would be "cheaper" instead of reespecifying the whole set, to say
"exception"s: ["tenga"]

On a sidenote: where can I find the default list that elasticsearch
uses when specifying ["es"] as stopwords???

--
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.