https://bugzilla.wikimedia.org/show_bug.cgi?id=27112
Sean Pringle <sprin...@wikimedia.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sprin...@wikimedia.org
--- Comment #4 from Sean Pringle <sprin...@wikimedia.org> ---
I assume the 'yuck' refers to temporary/filesort. Since the ORDER clause
contains columns from both tables MySQL can't use an index for ordering.
`revisions` has an index on rev_page,rev_id so doing both WHERE and ORDER on
rev_* fields gives:
explain SELECT * FROM `revision` JOIN `page` ON rev_page=page_id WHERE
rev_page >= 1157 and rev_page < 1158 ORDER BY rev_page, rev_id\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: revision
type: range
possible_keys: PRIMARY,page_timestamp
key: PRIMARY
key_len: 4
ref: NULL
rows: 1
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: page
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: enwiki.revision.rev_page
rows: 1
Extra:
Will the page_id range always be so small?
Using a larger range causes the query optimizer to switch table join order and
fall back on temporary/filesort again. We could force it with STRAIGHT_JOIN
but at the risk of hitting far more rows...
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
