https://bugzilla.wikimedia.org/show_bug.cgi?id=2170
Platonides <platoni...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #15 from Platonides <platoni...@gmail.com> 2010-04-15 11:09:13 UTC
---
Vasiliev implementation was reverted on r27436.
However, I don't think we can make it faster without adding a category_random,
it seems quite good:
EXPLAIN SELECT page_namespace, page_title FROM page USE INDEX(page_random) JOIN
categorylinks ON page_id = cl_from WHERE page_is_redirect = 0 AND page_random
>= 0.15564 AND cl_to = 'GFDL' ORDER BY page_random LIMIT 1;
Both select_types SIMPLE:
+-------------+------+-----------------+-------------+------------------------+
|table |type |key | key_len |ref | Extra |
+-------------+------+-----------+-----+-------------+------------------------+
|page |range |page_random| 8 |NULL |Using where |
|categorylinks|eq_ref|cl_from | 261 |page_id,const|Using where; Using index|
+-------------+------+-----------+-----+-------------+------------------------+
It would change to Using temporary; Using filesort if we weren't using a LIMIT,
but that's not the case.
Accessing the pages on the category is O(1), the problem is that for all the
results it needs to go to page to see the page_random. And for large categories
that would be a worse case of checking thousands of entries.
My testing shows that in practise it is run in a fraction of second, probably
due to the index + random numbers uniformly distributed.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
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
