[SERVER-38235] sort order on multi key index queries not as expected Created: 24/Nov/18 Updated: 27/Oct/23 Resolved: 26/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance, Querying, WiredTiger |
| Affects Version/s: | 3.6.8, 4.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Stefan Kaes | Assignee: | Danny Hatcher (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Steps To Reproduce: | Please run the attached script. It returns the documents in reverse order to what is expected. |
| Participants: |
| Description |
|
I have a system which stores documents that have an array valued field which contains pairs of metric names and values. I also have a compound index on this field which should enable querying for all documents containing a metric with a given name and returning them sorted by metric value. However, it looks like sorting works correctly only of the first element of the array. I'm pretty sure it did work as expected in previous MongoDB versions, but I'm not sure when it stopped working. I did work around the issue using the aggregation framework to get the correct sorting, but this has slowed down queries a lot. |
| Comments |
| Comment by Danny Hatcher (Inactive) [ 26/Dec/18 ] |
|
Hello Stefan,
I'm glad to hear that you were able to resolve your issue.
Thank you,
Danny |
| Comment by Stefan Kaes [ 22/Dec/18 ] |
|
You can close this ticket. |
| Comment by Stefan Kaes [ 22/Dec/18 ] |
|
Hello Daniel, thx for your help and the information provided. I solved my problem by writing a separate metrics collection which has an entry for every metric in the original document. This more or less reduces the original collection to a KV/store. |
| Comment by Danny Hatcher (Inactive) [ 27/Nov/18 ] |
|
Hello Stefan, I'm sorry to hear that. The current expectation is for us to end-of-life the 3.4 series in June 2019. At that point we would stop releasing bug fixes via minor releases but of course you are welcome to keep using the software past that date. Do you have an example of some of your documents and the queries that you are trying to run against them? There may be some quick wins that we can recommend that would improve their performance regardless of the index sorting change. Please note that this is a public project so do not post anything that would be considered private. Thank you very much, Daniel Hatcher |
| Comment by Stefan Kaes [ 27/Nov/18 ] |
|
BTW, I think adding an explanation to the user manual on how indexes on array fields work would be quite an improvement. |
| Comment by Stefan Kaes [ 27/Nov/18 ] |
|
Hi Danny, thx for the quick response. I have checked my code against version 3.4.18 and it works fine. Seems like this change is exactly what caused my problems. Unfortunately, this makes my indexes relatively useless, even though index contains all entries in the required order. Some of my collections using this kind of index are rather large and therefore queries have become really slow. I will have to consider either staying on 3.4 or switching to some other database technology. |
| Comment by Danny Hatcher (Inactive) [ 26/Nov/18 ] |
|
Hello Stefan, In 3.6, Thank you, Danny |