It all depends on how much security you want for your session.
In the low security scenario you can hit the user table in the database only on login verification and then keep all the required user data in the session variables (not their password or other sensetive data) and simply assume nobody has hijacked the session (or will).
The only other time you would need to hit the user table in this scenario is when you need to save off some user data, like a change in preferences etc. You could also serialize the session into a string for database storage on logout too so that it can be reconstructed when they next log in.
In the higher security scenario, you keep more information in the database and trust the session less, using it only to identify the user (and perhaps validating both the session, IP address and user agent etc against those that were logged in with).
It's a trade off between performance and security. Of course the worst that can happen with a session hijack in this situation (assuming you have no special privileges for some users) is that someone manages to cheat on your game by pretending to be someone else ;-)
