The behavior here is that it requires unique rows (an entity collection fetch), and due to the sorting on a field not in the projection, it can't emit distinct. This alone makes it switch to client-side paging (this isn't as lame as it sounds btw, it fetches rows per page from the server, not the whole set and then pages through it).
The reason for this is that there are situations where the original behavior, with 'are there unique rows?' and distinct checks sometimes flagged sets as 'OK' while there weren't unique rows causing pages to have less rows than you'd expect. So, to stay on the safe side we concluded it's better to switch to client side paging in those areas so the right rows were returned than return the wrong data.
You can set the engine to use the original behavior in all cases, which isn't recommended, by setting DynamicQueryEngineBase.DistinctFilteringPreferenceDefault to DistinctFilteringPreferenceType.Legacy.
You can also set this per-call. To do that you have to create a derived class from the DataAccessAdapter class like I have done below:
public class LegacyAdapter : DataAccessAdapter
{
protected override DynamicQueryEngineBase CreateDynamicQueryEngine()
{
var toReturn = base.CreateDynamicQueryEngine();
((DynamicQueryEngine)toReturn).DistinctFilteringPreferenceToUse = DistinctFilteringPreferenceType.Legacy;
return toReturn;
}
}
If you use the above adapter class instead of the normal DataAccessAdapter class, you'll get the legacy behavior here and it will issue a server-side paging query.
Hope this helps.
ps: I know for this particular situation it could conclude the right thing. We are aware of that and will try to make it do a better job in a future version.