[Bug 27112] select of revisions for stub history files does not explicitly order revisions

2013-09-10 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=27112

--- Comment #5 from Ariel T. Glenn ar...@wikimedia.org ---
It's possible to request a dump by arbitrary page range (and in fact that
feature is used), so no, we can't guarantee that the range will be small,
unfortunately.

We really only need this for the stub dumps; maybe I can tailor the queries in
that special case (yuck but less yuck than temporary/filesort).

-- 
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


[Bug 27112] select of revisions for stub history files does not explicitly order revisions

2013-09-09 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=27112

--- Comment #2 from Ariel T. Glenn ar...@wikimedia.org ---
So does anyone on this bug have any objections if I explicitly ORDER BY rev_id
ASC at the end of that query? Is that going to kill performance or break some
subtle thing in the dumps as they are now?

-- 
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


[Bug 27112] select of revisions for stub history files does not explicitly order revisions

2013-09-09 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=27112

--- Comment #3 from Ariel T. Glenn ar...@wikimedia.org ---
the explain doesn't look good, yuck:

explain SELECT  *  FROM `page` INNER JOIN `revision` ON ((page_id=rev_page)) 
WHERE page_id = 1157 AND page_id  1158  ORDER BY page_id ASC, revision.rev_id
ASC;
++-+--+---++-+-+-+--+--+
| id | select_type | table| type  | possible_keys  | key |
key_len | ref | rows | Extra   
|
++-+--+---++-+-+-+--+--+
|  1 | SIMPLE  | page | range | PRIMARY| PRIMARY | 4   
   | NULL|1 | Using where; Using temporary; Using filesort
|
|  1 | SIMPLE  | revision | ref   | PRIMARY,page_timestamp | PRIMARY | 4   
   | elwiki.page.page_id |9 | 
|
++-+--+---++-+-+-+--+

Prolly need to specify which key or something in here...

-- 
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


[Bug 27112] select of revisions for stub history files does not explicitly order revisions

2013-09-09 Thread bugzilla-daemon
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


[Bug 27112] select of revisions for stub history files does not explicitly order revisions

2011-08-12 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=27112

Diederik van Liere dvanli...@gmail.com changed:

   What|Removed |Added

   Keywords||analytics
 CC||dvanli...@gmail.com

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- 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


[Bug 27112] select of revisions for stub history files does not explicitly order revisions

2011-02-02 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=27112

--- Comment #1 from Brion Vibber br...@pobox.com 2011-02-02 19:28:14 UTC ---
Note that mismatched ordering might really confuse the dump prefetching code,
which IIRC assumes a consistent order of (page_id, rev_id).


There are many perfectly 100% legit reasons for a later rev_id to have an
earlier timestamp, chief among them:
* import
* restore from deletion (for things deleted prior to rev_id being stored in
archive table, at least)

as well as mundane things such as server clock skew.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- 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


[Bug 27112] select of revisions for stub history files does not explicitly order revisions

2011-02-02 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=27112

Ariel T. Glenn ar...@wikimedia.org changed:

   What|Removed |Added

   Severity|enhancement |minor

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- 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