Last modified: 2014-05-12 11:37:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67218, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65218 - slow query Flow\Formatter\ContributionsQuery::queryRevisions
slow query Flow\Formatter\ContributionsQuery::queryRevisions
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Flow (Other open bugs)
master
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-12 11:36 UTC by Sean Pringle
Modified: 2014-05-12 11:37 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Sean Pringle 2014-05-12 11:36:30 UTC
The following query form is starting to run slow on the x1 cluster for flowdb:

flowdb> explain SELECT /* Flow\Formatter\ContributionsQuery::queryRevisions */  *  FROM `flow_revision`,`flow_workflow`,`flow_tree_node`   WHERE (rev_user_id > 1509667) AND (rev_id < '*�*�\0\0\0\0\0\0') AND workflow_wiki = 'mediawikiwiki' AND rev_type = 'post-summary'  ORDER BY rev_id DESC LIMIT 51\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: flow_revision
         type: ref
possible_keys: PRIMARY,flow_revision_user,flow_revision_type_id
          key: flow_revision_type_id
      key_len: 18
          ref: const
         rows: 55
        Extra: Using index condition; Using where; Using filesort
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: flow_workflow
         type: ref
possible_keys: flow_workflow_lookup
          key: flow_workflow_lookup
      key_len: 18
          ref: const
         rows: 649
        Extra: Using index condition
*************************** 3. row ***************************
           id: 1
  select_type: SIMPLE
        table: flow_tree_node
         type: index
possible_keys: NULL
          key: flow_tree_constraint
      key_len: 13
          ref: NULL
         rows: 20065
        Extra: Using index
3 rows in set (0.26 sec)

While tolerable now thanks to optimizer choosing index condition pushdown, it looks like a candidate for future pain. Should it be possible to trigger a three-way cross join?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links