I think the bigger strain on the database would almost certainly be to make multiple smaller queries rather than one large one.  Databases are efficient at returning very large result sets from a single SELECT query, and that is usually advised as the preferred approach by database administrators for this situation.  Also, this query has no joins, and only the pk is returned, making it very fast.  Databases shouldn't have any trouble with it as a single query.

On the other hand, if slicing were done (as in the original code), the number of individual queries required could end up in the hundreds or even thousands fairly easily.  For example, to return 1 million records at the default batch size requires about 1000 queries, whereas 1 query would have sufficed.  That would be the bigger strain on the database by far, in my opinion.

I'm not a database administrator, and I have not personally run any profiling to compare the different approaches (well, except for some trivial testing against 1 million user IDs).  So, if you think the original code is the better solution, I respect that, and will update the patch back to the original way of handling the batches.  Just let me know...