Our default user listing query at admin/people returns duplicate users. Those users get filtered upon display but we end up with crazy paging. Here is the current query:
SELECT u.uid AS uid, u.name AS name, u.status AS status, u.created AS created, u.access AS access FROM users u LEFT OUTER JOIN users_roles ur ON u.uid = ur.uid WHERE (u.uid <> 1) ORDER BY u.created DESC LIMIT 0, 50
To see the problem, use devel_generate to create 100 users with multiple roles (requires latest devel_generate). Then view admin/people. I recommend changing the limit in user_admin_account() from 50 to 5 so you can quickly see that at times, only 3 or 4 rows are on each page.
We have to be careful how we fix this. In D6 we always add a DISTINCT which murders performance for a site with many users (economist.com has 3M users). We should not join to roles table IMO when no role condition is present. We can user_load_multiple() on each row, IMO. When a role condition is present, we should join on role but still not DISTINCT since only one role can be selected at a time. See #604290: user admin page slow with lots of users for a D6 patch.
Comment | File | Size | Author |
---|---|---|---|
#5 | user_admin.patch | 2.51 KB | JeremyFrench |
#4 | user_admin.patch | 2.3 KB | JeremyFrench |
#3 | user_admin.patch | 2.59 KB | JeremyFrench |
Comments
Comment #1
catchSo getting all the uids, then a user_load_multiple() seems like it'll hopefully fix the paging without murdering the performance. If user_load_multiple() is badly behaved, we still have time to change the internals before release.
Comment #2
JeremyFrench CreditAttribution: JeremyFrench commentedI am working on a patch. Should be ready today.
Comment #3
JeremyFrench CreditAttribution: JeremyFrench commentedHere is a first stab at a patch.
Comment #4
JeremyFrench CreditAttribution: JeremyFrench commentedThere was a tab in the patch. Removed it.
Comment #5
JeremyFrench CreditAttribution: JeremyFrench commentedRemove the distinct from the count query in this patch
Comment #6
moshe weitzman CreditAttribution: moshe weitzman commentedWell done. Note that UserAdminTestCase already keeps us honest. No new testing is needed IMO.
Comment #9
moshe weitzman CreditAttribution: moshe weitzman commentedComment #10
webchickThanks! I am not sure why I didn't commit this back when I first read it. Sorry about that.
Committed to HEAD.