If it's not too much trouble, could we do the watchlist without string comparisons? I bet a table like this speed things up:
user_id article_id ------- ---------- 284 298 284 1598 284 6503 284 1364 284 3305
Then, we could link the tables, like:
SELECT * FROM cur, watch WHERE cur_id = watch_article_id AND watch_user_id = 284
(Again, I'm not sure of the syntax: I made up a non-existent table!)
Would this work? How hard would it be to implement? How much would it help?
Ed Poor
Poor, Edmund W wrote:
If it's not too much trouble, could we do the watchlist without string comparisons? I bet a table like this speed things up:
user_id article_id
[..]
Would this work? How hard would it be to implement?
For the most part it would be very straightforward; I didn't implement it when it was first suggested because I wasn't sure how to get the associated talk pages to come up in the list easily. This is a key feature of the watchlist and I didn't want to break it without recourse. We could add them to the wacthlist table along with the main pages when a user adds a page; but if the talk page is created later, we'd have to go update everyone's watchlists on page creation. (Hmm, could work.)
Using namespace and title instead of cur_id would make it more straightforward, but wouldn't give the advantage of automatically preserving a page in the list after a page move. (Though, we could easily issue an update on page move that way.)
How much would it help?
Somewhat, particularly for the small but promiscuous few who have very very long watchlists.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org