It's not really all that good of an idea to do database stuff in a JSF bean constructor. Since JSF beans are constructed using the no-arguments constructor, the only way to get a database connection is to reach out and grab it, and that violates the Inversion of Control (IoC) approach that JSF promotes. Using @PostConstruct, you can inject in a persistency mechanism from outside. Which aside from being ideologically pure

makes it easier to set up
unit tests.
It sounds like you're reading detail information in, even though you may not intend to use it. Don't bother. I normally invoke an "init()" method to clear out reusable beans or initialize from a constructor (and/or @PostConstruct) for short-scope beans. The init() method is usually invoked from constructor or @PostConstruct and by lead-in action methods (such as beginAdd/beginEdit()).
For long-term properties, consider supplying them in long-term beans. For example, I have apps where the selection menus are mostly constant and are the same for all users. Rather than create and destroy them every time, I create them in a separate bean that has application scope. One trip to the database, one build operation, one copy of the data, many uses.