You can pull out all rows relating to the groups a user is a member of, and process them on the RADIUS server using the group name as a key. This could be done in one query if you were feeling adventurous, or probably more easily with two.
That's a very reasonable suggestion, and would not I suspect be hard to code. However, I think it would prevent certain types of dynamic processing in the SQL side, so it would ideally be an optional configuration e.g. "bulk_query_groups = yes/no" or something.
Another possible alternative improvement using the current scheme,would be to bring all the rows relating to a group down, then evaluate them, and only continue querying if fall-through was true, or the check items didn't match.
Good suggestion - but it already does that. See lines 610 (the "for" loop dependent on the dofallthrough flag being 1) and 665/699 (setting of the dofallthrough flag based on the per-group Fall-Through reply items) of rlm_sql.c in todays CVS checkout. I'm fairly sure the CVS module has done that for months
Our SQL server is running on the campus webserver, it's horribly overloaded and horribly slow.
Then frankly I'm surprised you aren't experiencing more problems
Don't get me wrong, I appreciate you fixing the horribly broken SQL code, I was just suggesting some things that might improve efficiency.
I didn't fix it - the only code I've ever contributed to FreeRadius has been tiny 1-liners in the bug tracker. I was speaking up in support of whoever did.