Add index to the votingapi_vote table

Moving to the VotingAPI queue.

Would adding an index for just the timestamp column be sufficient? Or should it be used in combination with another column?

I am very sorry... fixing the issue summary.

So in the example in the summary I think an index on just the timestamp would do. Something tells me it should be vid and timestamp would be more practical. In no way am I a database expert. If you want an answer to this question, the issue queue is not the best place to ask. Try irc or find on of the contributors to the database layer in drupal core an email them.

This belongs to the rate-modules issue queue, as it is the (only known) module actually doing this increasingly slow query. It is an easy fix, adding one multi-column index.

So in the example in the summary I think an index on just the timestamp would do. Something tells me it should be vid and timestamp would be more practical. In no way am I a database expert.

Index on timestamp is not enough, the single index needs to cover both vote_source and timestamp. "vid" is not an option for this use case.

If you want an answer to this question, the issue queue is not the best place to ask. Try irc or find on of the contributors to the database layer in drupal core an email them.

IMO the issue queue is just the right place to ask this, if it's in the correct module (rate). Except in the case that the module creator(s) happen to be more active on IRC and not so keen on checking issue queues.

To get the index, apply the attached patch or simply run this with drush:
drush php-eval "db_add_index('votingapi_vote', 'rate_bot', array('vote_source', 'timestamp'));"

Here is a better patch that works againt latest HEAD (not master branch). The index is also checked/added during module install now.

Has anyone been using this patch over the past 3 years that can report any issues?

#6 LGTM except for the codestyle (missed spaces)

Drupal 7 is EOL. Issue will be closed, but patches are still here