There is a reason that that the introductory materials for Core Data do not spend any time on memory management. Core Data is very efficient in memory use and handles it automatically. If your app encounters low memory, Core Data will convert live objects to faults if they are not being actively accessed.
In the case of tables, if you use a fetched results controller, you won't be loading in all the managed objects in one gulp but only those whose attributes you directly access. For example, suppose you use an indexed table with thousands of alphabetized objects. When the table first loads, only the 10 or so managed objects needed to populate the visible cells are in memory. If you use the index to just to "Z", only the managed objects needed to display those few cells being displayed at once under "Z" are loaded into memory. Even if you scroll through a non-indexed table, your memory use is low as the table knows to ask for cells only for rows that actually readable.
Premature optimization is the source of all programming evil. Don't waste time and add complexity trying to prevent problems you may never have.
In the specific case of Core Data, it handles 95% of all memory issue for you. That is one of its major advantages. I seldom pay any attention to Core Data's memory use.
Instead, start with the simplest implementation. You shouldn't worry about memory use until you've tested and found a problem.