[SERVER-12287] Query containing $regex operator: performance regression Created: 08/Jan/14 Updated: 11/Jul/16 Resolved: 08/Jan/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Performance, Querying |
| Affects Version/s: | 2.5.4 |
| Fix Version/s: | 2.5.5 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Davide Italiano | Assignee: | Davide Italiano |
| Resolution: | Done | Votes: | 0 |
| Labels: | query | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux ip-10-0-0-15 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
Some queries using $regex operator (e.g. "starts with") are slower in 2.6 than in 2.4. This has been noticeable on the mongo-perf suite regex test.
$explain output for 2.4.8
$explain output for trunk (hash 5432e4836aec87fe9b53efe19d3bfff90ef0f6ef)
|
| Comments |
| Comment by Scott Hernandez (Inactive) [ 06/Feb/14 ] |
|
Please file a new issue. Include some sample data (or your dumped data), your indexes and a full explain (pass in true to explain). |
| Comment by rgpublic [ 06/Feb/14 ] |
|
Um, is this really fixed with 2.5.5? I recently tried to upgrade from 2.4.9 to 2.5.5 and I'm experiencing catastrophic regex query times with 2.5.5 so I had to downgrade again. My query simply is: { 2.4.9 gives me this query plan: "cursor": "BtreeCursor type_folder multi", 2.5.5 gives this query plan: "cursor": "Complex Plan", This plan is then running for literally ages |
| Comment by Daniel Pasette (Inactive) [ 08/Jan/14 ] |
|
Fixed by enabling query plan cache. See: |
| Comment by Davide Italiano [ 08/Jan/14 ] |
|
The problem is gone away now that cache for query plans. Apparently the time spent to generate all the query plans overcomes the benefits, as you guessed. 2.5.5 as per today is up to about 14% faster than baseline (2.4.8), see attachment. |
| Comment by Daniel Pasette (Inactive) [ 08/Jan/14 ] |
|
can you try this same test against HEAD? commit 0d818f66f1a2429ce65b19afd9b5e7b64076732b |