I have the same concern but I didn't mention it in my response. I think you effectively get what you are looking for for free.
If you perform a query locally and then walk the results, it will load things lazily but Andrey said the performance aspect of this is not an issue. The penalty would only be incurred on a remote connection. So only the parts of the results that you touch are brought into memory (the cache actually). Assuming the performance penalty is negligible, this is much better than having to specify a fetch plan to narrow the results. Try some tests and monitor the second level cache which should correspond to the heap. I just did some simple tests and the behavior is as expected. So I think this now becomes a matter of cache management rather than fetching (at least locally). On Wednesday, April 2, 2014 11:59:13 AM UTC-4, cp2 wrote: > > Andrey -- > I am glad you will be implementing fetch plan for local storage. > > BTW: odbuser2 and I seem to be concerned about opposite things. > They want to make sure everything in the fetch plan *is* returned. I want > to be sure *nothing more* than in the fetch plan is returned. > > I am concerned about not instantiating any more objects on the java heap > than necessary. If the fetch plan limits what I pull in to only what I ask > for, then I can use a smaller heap, and avoid GC issues. A smaller heap in > turn leaves more RAM on the machine for direct memory. > > This all assumes I correctly understand the OrientDB caching model :) > > > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
