# Major performance degradation on 0.12 for queries like \*:\* AND NOT \ **URL:** \ **Category:** Elasticsearch\ **Created:** [October 25, 2010, 10:33pm UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476 "2010-10-25T22:33:09Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [October 25, 2010, 10:33pm UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/1 "2010-10-25T22:33:09Z")
Hi, I am seeing some really nasty performance with negative queries on 0.12. I know these queries performed fine on a pre 0.12 release (maybe 0.10 or 0.11). To test that it wasn't something on my side, I created th sample twitter index and add a couple of test docs (basically, what is in the REST docs). Then I perform query like this: [http://localhost:9200/twitter/\_search?q=](http://localhost:9200/twitter/_search?q=)_:_%20AND%20NOT%20elastic Where the non-URL encoded query is: _:_ AND NOT elastic The query takes a very long time and pegs a CPU while it is running. I can open a ticket to track further, if needed or verify any updates. Thanks! Paul ---
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [October 25, 2010, 10:42pm UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/2 "2010-10-25T22:42:50Z")
FYI, playing around more, the performance degradation seems to be related to the extra AND _:_ I am adding to the query that ES does not need (but pure Lucene query syntax does). So, I have an update (remove extraneous _:_) on my side that should hopefully address. Thanks On Oct 25, 4:33 pm, Paul [ppea...@gmail.com](mailto:ppea...@gmail.com) wrote: > Hi, > I am seeing some really nasty performance with negative queries on > 0.12. I know these queries performed fine on a pre 0.12 release (maybe > 0.10 or 0.11). To test that it wasn't something on my side, I created > th sample twitter index and add a couple of test docs (basically, what > is in the REST docs). > > Then I perform query like this:[http://localhost:9200/twitter/\_search?q=\*:\*%20AND%20NOT%20elastic](http://localhost:9200/twitter/_search?q=*:*%20AND%20NOT%20elastic) > > Where the non-URL encoded query is: > _:_ AND NOT elastic > > The query takes a very long time and pegs a CPU while it is running. > > I can open a ticket to track further, if needed or verify any updates. > > Thanks! > Paul ---
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [October 25, 2010, 11:58pm UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/3 "2010-10-25T23:58:36Z")
Further update, by removing the unseeded _:_ I have confirmed that search times are blazing again. On Oct 25, 4:42 pm, Paul [ppea...@gmail.com](mailto:ppea...@gmail.com) wrote: > FYI, playing around more, the performance degradation seems to be > related to the extra AND _:_ I am adding to the query that ES does not > need (but pure Lucene query syntax does). So, I have an update (remove > extraneous _:_) on my side that should hopefully address. > > Thanks > > On Oct 25, 4:33 pm, Paul [ppea...@gmail.com](mailto:ppea...@gmail.com) wrote: > > > Hi, > > I am seeing some really nasty performance with negative queries on > > 0.12. I know these queries performed fine on a pre 0.12 release (maybe > > 0.10 or 0.11). To test that it wasn't something on my side, I created > > th sample twitter index and add a couple of test docs (basically, what > > is in the REST docs). > > > Then I perform query like this:[http://localhost:9200/twitter/\_search?q=\*:\*%20AND%20NOT%20elastic](http://localhost:9200/twitter/_search?q=*:*%20AND%20NOT%20elastic) > > > Where the non-URL encoded query is: > > _:_ AND NOT elastic > > > The query takes a very long time and pegs a CPU while it is running. > > > I can open a ticket to track further, if needed or verify any updates. > > > Thanks! > > Paul ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [October 26, 2010, 4:51am UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/4 "2010-10-26T04:51:25Z")
On Mon, 2010-10-25 at 16:58 -0700, Paul wrote: > Further update, by removing the unseeded _:_ I have confirmed that > search times are blazing again. Paul - please keep an eye out for other slowdowns - I am seeing some very slow responses on 0.12 for queries which were working well before. clint -- Web Announcements Limited is a company registered in England and Wales, with company number 05608868, with registered address at 10 Arvon Road, London, N5 1PR. ---
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [October 26, 2010, 7:47am UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/5 "2010-10-26T07:47:07Z")
Hey Clint, I can confirm that this is the only slow down we have run into. I've pumped millions of real world queries through since, mostly consisting of complex nested fielded boolean queries sorted by date and there are no other performance differences. I'm definitely only touching a fraction of the search functionality, though. Thanks, Paul On Oct 25, 10:51 pm, Clinton Gormley [clin...@iannounce.co.uk](mailto:clin...@iannounce.co.uk) wrote: > On Mon, 2010-10-25 at 16:58 -0700, Paul wrote: > > > Further update, by removing the unseeded _:_ I have confirmed that > > search times are blazing again. > > Paul - please keep an eye out for other slowdowns - I am seeing some > very slow responses on 0.12 for queries which were working well before. > > clint > > -- > Web Announcements Limited is a company registered in England and Wales, > with company number 05608868, with registered address at 10 Arvon Road, > London, N5 1PR. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [October 26, 2010, 9:03am UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/6 "2010-10-26T09:03:56Z")
Hi, I added an optimization in match\_all cases (including query string like _:_), but, that optimization has resulted in excessive processing in some cases. Easily fixable while still maintaing the optimization. I have created a branch for 0.12 on github with the fix: [GitHub - elastic/elasticsearch at 0.12](http://github.com/elasticsearch/elasticsearch/tree/0.12). I will release 0.12.1 pretty soon (likely today) as this is a major regression. Can you give it a go? -shay.banon On Tue, Oct 26, 2010 at 9:47 AM, Paul [ppearcy@gmail.com](mailto:ppearcy@gmail.com) wrote: > Hey Clint, > I can confirm that this is the only slow down we have run into. I've > pumped millions of real world queries through since, mostly consisting > of complex nested fielded boolean queries sorted by date and there are > no other performance differences. I'm definitely only touching a > fraction of the search functionality, though. > > Thanks, > Paul > > On Oct 25, 10:51 pm, Clinton Gormley [clin...@iannounce.co.uk](mailto:clin...@iannounce.co.uk) wrote: > > > On Mon, 2010-10-25 at 16:58 -0700, Paul wrote: > > > > > Further update, by removing the unseeded _:_ I have confirmed that > > > search times are blazing again. > > > > Paul - please keep an eye out for other slowdowns - I am seeing some > > very slow responses on 0.12 for queries which were working well before. > > > > clint > > > > -- > > Web Announcements Limited is a company registered in England and Wales, > > with company number 05608868, with registered address at 10 Arvon Road, > > London, N5 1PR. ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [October 26, 2010, 10:12am UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/7 "2010-10-26T10:12:56Z")
Hi kimchy > I added an optimization in match\_all cases (including query string > like _:_), but, that optimization has resulted in excessive processing > in some cases. Easily fixable while still maintaing the optimization. > I have created a branch for 0.12 on github with the fix: > [GitHub - elastic/elasticsearch at 0.12](http://github.com/elasticsearch/elasticsearch/tree/0.12). I will > release 0.12.1 pretty soon (likely today) as this is a major > regression. Can you give it a go? Can I restart one node at a time? Also, does this affect constant\_score as well as match\_all? thanks clint > -shay.banon > > On Tue, Oct 26, 2010 at 9:47 AM, Paul [ppearcy@gmail.com](mailto:ppearcy@gmail.com) wrote: > Hey Clint, > I can confirm that this is the only slow down we have run > into. I've > pumped millions of real world queries through since, mostly > consisting > of complex nested fielded boolean queries sorted by date and > there are > no other performance differences. I'm definitely only touching > a > fraction of the search functionality, though. > > ``` > Thanks, > Paul > > > On Oct 25, 10:51 pm, Clinton Gormley > wrote: > > On Mon, 2010-10-25 at 16:58 -0700, Paul wrote: > > > Further update, by removing the unseeded *:* I have > confirmed that > > > search times are blazing again. > > > > Paul - please keep an eye out for other slowdowns - I am > seeing some > > very slow responses on 0.12 for queries which were working > well before. > > > > clint > > > > -- > > Web Announcements Limited is a company registered in England > and Wales, > > with company number 05608868, with registered address at 10 > Arvon Road, > > London, N5 1PR. > > ``` -- Web Announcements Limited is a company registered in England and Wales, with company number 05608868, with registered address at 10 Arvon Road, London, N5 1PR. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [October 26, 2010, 10:28am UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/8 "2010-10-26T10:28:25Z")
Yes, you can restart one node at a time (i.e. a rolling upgrade). It does not affect constant score, only places where one uses match\_all (query/filter) or _:_. -shay.banon On Tue, Oct 26, 2010 at 12:12 PM, Clinton Gormley [clinton@iannounce.co.uk](mailto:clinton@iannounce.co.uk)wrote: > Hi kimchy > > > I added an optimization in match\_all cases (including query string > > like _:_), but, that optimization has resulted in excessive processing > > in some cases. Easily fixable while still maintaing the optimization. > > I have created a branch for 0.12 on github with the fix: > > [GitHub - elastic/elasticsearch at 0.12](http://github.com/elasticsearch/elasticsearch/tree/0.12). I will > > release 0.12.1 pretty soon (likely today) as this is a major > > regression. Can you give it a go? > > Can I restart one node at a time? > > Also, does this affect constant\_score as well as match\_all? > > thanks > > clint > > > -shay.banon > > > > On Tue, Oct 26, 2010 at 9:47 AM, Paul [ppearcy@gmail.com](mailto:ppearcy@gmail.com) wrote: > > Hey Clint, > > I can confirm that this is the only slow down we have run > > into. I've > > pumped millions of real world queries through since, mostly > > consisting > > of complex nested fielded boolean queries sorted by date and > > there are > > no other performance differences. I'm definitely only touching > > a > > fraction of the search functionality, though. > > > > ``` > > Thanks, > > Paul > > > > On Oct 25, 10:51 pm, Clinton Gormley > > wrote: > > > On Mon, 2010-10-25 at 16:58 -0700, Paul wrote: > > > > Further update, by removing the unseeded *:* I have > > confirmed that > > > > search times are blazing again. > > > > > > Paul - please keep an eye out for other slowdowns - I am > > seeing some > > > very slow responses on 0.12 for queries which were working > > well before. > > > > > > clint > > > > > > -- > > > Web Announcements Limited is a company registered in England > > and Wales, > > > with company number 05608868, with registered address at 10 > > Arvon Road, > > > London, N5 1PR. > > > > ``` > > -- > Web Announcements Limited is a company registered in England and Wales, > with company number 05608868, with registered address at 10 Arvon Road, > London, N5 1PR. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:17am UTC](https://discuss.elastic.co/t/major-performance-degradation-on-0-12-for-queries-like-and-not-queryterm/3476/9 "2017-07-06T04:17:34Z")