Please refer to original issue and then Moshe's comment here.
http://groups.drupal.org/node/19185#comment-81786

Adding to issue queue so this can be tracked and verified to confirm it indeed helps performance.

Comments

amitaibu’s picture

As mentioned by Moshe, we'd like to see some benchmarks to support this change.

msonnabaum’s picture

I just had an issue with this where I had a view of users with a content profile relationship, so it was joining on both og_uid.uid and og_uid.nid:

LEFT JOIN og_uid og_uid ON users.uid = og_uid.uid
LEFT JOIN node node_og_uid ON og_uid.nid = node_og_uid.nid

Adding an index on og_uid.uid made the query execution time go from 20s to 170ms. Quite an improvement.

Here are the before and after EXPLAINs:

table type possible_keys key key_len ref rows Extra
1 SIMPLE users_roles ref PRIMARY,rid rid 4 const 4377 Using index; Using temporary; Using filesort
1 SIMPLE users eq_ref PRIMARY PRIMARY 4 databasename.users_roles.uid 1
1 SIMPLE users_roles2 eq_ref PRIMARY,rid PRIMARY 8 databasename.users.uid,const 1 Using where; Using index; Not exists
1 SIMPLE node_users ref node_type,uid uid 4 databasename.users.uid 1
1 SIMPLE og_uid index NULL PRIMARY 8 NULL 8363 Using index
1 SIMPLE node_og_uid eq_ref PRIMARY PRIMARY 4 databasename.og_uid.nid 1 Using index
1 SIMPLE node_og_uid__og_subgroups ref PRIMARY PRIMARY 4 databasename.node_og_uid.nid 1 Using where; Using index
1 SIMPLE node_users_node_data_field_profile_picture eq_ref PRIMARY PRIMARY 4 databasename.node_users.vid 1
1 SIMPLE node_users_node_data_field_lastname eq_ref PRIMARY PRIMARY 4 databasename.node_users.vid 1
table type possible_keys key key_len ref rows Extra
1 SIMPLE users_roles ref PRIMARY,rid rid 4 const 4377 Using index; Using temporary; Using filesort
1 SIMPLE users eq_ref PRIMARY PRIMARY 4 databasename.users_roles.uid 1
1 SIMPLE users_roles2 eq_ref PRIMARY,rid PRIMARY 8 databasename.users.uid,const 1 Using where; Using index; Not exists
1 SIMPLE node_users ref node_type,uid uid 4 databasename.users.uid 1
1 SIMPLE og_uid ref uid uid 4 databasename.users.uid 41 Using index
1 SIMPLE node_og_uid eq_ref PRIMARY PRIMARY 4 databasename.og_uid.nid 1 Using index
1 SIMPLE node_og_uid__og_subgroups ref PRIMARY PRIMARY 4 databasename.node_og_uid.nid 1 Using where; Using index
1 SIMPLE node_users_node_data_field_profile_picture eq_ref PRIMARY PRIMARY 4 databasename.node_users.vid 1
1 SIMPLE node_users_node_data_field_lastname eq_ref PRIMARY PRIMARY 4 databasename.node_users.vid 1
msonnabaum’s picture

Status: Active » Needs review
StatusFileSize
new846 bytes

And here's a patch.

pdrake’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new628 bytes

I also ran into a basic view which needs this index. This query is from a view of groups in which a user is active. Below are profiles of the query before and after.

| 1 | 0.34071700 | SELECT sql_no_cache n.title, n.TYPE, n.status FROM og_uid ou INNER JOIN node n ON ou.nid = n.nid WHERE ou.uid = ? AND ou.is_active >= 1 AND n.TYPE in('group') ORDER BY n.title
| 2 | 0.03641400 | SELECT sql_no_cache n.title, n.TYPE, n.status FROM og_uid ou INNER JOIN node n ON ou.nid = n.nid WHERE ou.uid = ? AND ou.is_active >= 1 AND n.TYPE in('group') ORDER BY n.title

This is the same as the above patch, but re-rolled against the latest 6.x-2.x and using db_add_index instead of SQL. Given that I changed this patch slightly, feel free to reset my RTBC back to needs review if necessary. Not sure what the proper status would be here.

Grayside’s picture

Issue tags: +Performance

Don't have time to think about this right now, but tagging for easy retrieval later.

Grayside’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)
Issue tags: -Performance

Automatically closed -- issue fixed for 2 weeks with no activity.