I just learned about CDataProviderIterator and just wanted to remark that, in my opinion, this is entirely the wrong approach.
The problem it solves, is not a database problem - that problem was actually solved by databases, which (in general) are very good at delivering a large result set in a progressive way, without keeping them all in memory.
The problem is a limitation of the Active Record implementation, which by design is only capable of constructing the complete result-set in-memory and returning it as a whole.
The documentation neglects to point out an important limitation of this work-around: if you’re going to iterate over millions of users in the database, for example, to send them each a personalized e-mail, you would have to order them by an auto-increment primary key, or date/time created, in ascending order. Since the iterator actually performs independent queries for “pages” of results, if you were to order the queries by, say, date of birth, and a new user signs up while this lengthy batch of queries is running, some unlucky user would get skipped.
A safer (and more memory-efficient, bandwidth-efficient, and CPU-efficient) approach, would be to construct the query for the root entity in such a way that you avoid multiple tuples for the same root entity. For example, if Article has a many-to-many relation to Category, do not join the article-table to the category-table, since this causes the article data to repeat for every category - sure, you save a round-trip to the database, but the database also has to construct a substantially larger result-set, serialize it, send it over the network (if the DB server is separate from the app server); the client then has to unserialize a larger result-set, AR has to detect and ignore duplicate data, wasting more memory and CPU time.
All those issues aside, this of course also means you can’t read through the result-set and construct entities progressively, which is my initial point.
Take a peak at for example NotORM, which avoids heavy result-sets and complex join-queries by using a much simpler approach.
The idea that fewer queries automatically means better performance is an old myth, and while in some rare cases that may be true, for the large majority of queries, it just isn’t true - unless your DB server is on an entirely different network from your app server, in terms of performance, the number of roundtrips is most likely the least of your concerns.