I agree with this, it has been on my personal wishlist for a long time. Thanks for raising the subject again.

Though consider as well that we really think people should use "all lazy" relations in almost all cases. It's very easy to turn a relation "eager" dynamically when a specific code section benefits from it, and it's very rare for this to have any beneficial effect on all your usage.
So this warrants the question: are you sure you're not just having some eager relations as a workaround for other problems?
For example, I often see people using EAGER aggressively because they want to detach (or close the Session) early on, for questionable reasons.

As Hardy suggests, it would be very useful for us to get some more details of which possible solutions would work best in your use case.

I think that ideally we should be able to fully disable the eager loading from the indexing plan, but still often the user could know better on what is more effective to load eagerly or not so a possible evolution would be to have such a fetch plan being defined for indexing only.

The big limitation in all of this, is that Hibernate ORM doesn't currently allow to "demote" a fetch plan to lazy when it's mapped as eager, and that is a very complex intimidating patch. So better get the requirements right before we start hacking

Avoiding to fetch specific columns is a different subject, with its very own complexities; for one, that's also not possible currently. The main issue though is that we don't really know which fields the user will need to create the indexed model, for example when using custom bridges or dynamic Analyzers, the current API exposes all of the entity to the extension points provided by the user.
So: yes we could do that, but not automatically unless we change the API to be more restrictive.