now I see how it works. And why I needed to develop that extra part of code to make it work in my case. Let me try to explain a bit further why.

The PagedReader class I'm developing to visualize data in the GUI requires some subclass with following protocol:

Using an implementation of this, you can page your data up, calculate how many pages there are, navigate to next / prev pages, and forth.

I've created an implementation for MagmaCollectionReader. But since this can be any MagmaCollectionReader; I had to take into account that the MagmaCollectionReader might still not be sorted yet.

BMTMagmaTodoRepository>>findTodosWithTitle: aString
^PRPagedReader on:
((items
where: [:eachTodo| eachTodo title match: aString]
distinct: false
sortBy: #dueDate
descending: false)
asPagedReaderSource)

So I have a where clause on one attribute, but are sorting on another one; so magma needs to do a background sort; leading to the implementation of above to make the total number of items work. I first used sortedBy: but that took around 15 seconds to do a sort of a test set of 7000 items, which off course was too long. I only needed to show the first 20 of them quickly, and in the background the server was sorting the rest for me.

Since I want to keep my abstraction of PagedReader to work on any MagmaCollectionReader (and let the repository - BMTMagmaTodoRepository - business logic do the sort) - so in fact separate both concerns; I had to implement it this way.

The remark you make about doing the where: clause first, taking the size, and then doing the sort is true; but only if you're not requiring distinct results.

I still have one further question about this. If the #fractionSorted for instance replies with: (2249/6065); does this then mean for sure that the GUI visualizing the query can show the first 2249 items correctly sorted ? I mean, if I for instance show items 1-20, there will come no other items 1-20 even if the sort is not done yet ? That the sort up to item 2249 is already correct? (This would be a very good thing) Or does this mean that just 2249/6065 percent of the result is sorted? (This would make it a rather bad thing?).

What I also noticed that if the server is doing this background sort, and I am already asking the next page; that there is something wrong with the priorities of both. What I would find reasonable is that the background sort should get a lower priority than me asking the next page. So that this next page is returned quickly, and the background sort due to its lower priority is kinda 'paused' for this short time. But I'm not sure if this does make any sense.