Open Radar

 
Summary:
When using the @count of a relationship in a fetch request predicate, querying one direction of the many-to-many relationship can result in large performance degradation due to not being able to use the compound index of the join table.

Steps to Reproduce:
Sample project is provided to demonstrate the different fetch requests.

Overview:
1. Create a Core Data model with many-to-many relationship A<<->>B.
2. Populate with a significant number of records. (5,000+ works pretty well)
3. Write a fetch request to find entities A which have to related B, and a request to find entities B which have no A. Common recommendations is for A:"manyBs.@count == 0" and for B:"manyAs.@count == 0"
4. Observe performance of each.

Expected Results:
Expect to see equivalent query performance regardless of A->B or B->A direction.

Actual Results:
Actually see dramatic differences depending on query direction: 0.0634sec for A->B on an iPhone 5 vs. 48.7783sec for B->A

Version:
Xcode 6.3.1 (6D1002), iOS 8.3 (12F70)

Notes:
Generating a secondary index solely on Z_2MANYBS column would help correct this, but add overhead and not fix any deployed apps. Seems it would be preferable if you could change the query generation to generate query matching what a predicate of "NONE manyAs != nil" generates, since it enables the existing compound index to be used.

Configuration:
iPhone 5 (Model A1428), but also Simulator

Attachments:
'ManyAToManyB.zip' was successfully uploaded.
(project at <https://github.com/pgor/ManyAToManyB>)