https://bugzilla.wikimedia.org/show_bug.cgi?id=29287
--- Comment #4 from Reedy <s...@reedyboy.net> 2011-06-06 19:02:01 UTC --- Basic api module added in r89588 --- Comment #5 from Brion Vibber <br...@wikimedia.org> 2011-06-06 19:02:01 UTC --- Those row counts are estimates to begin with, and the difference is pretty tiny (636k rows vs 658k rows? same order magnitude). I wouldn't assume that to help all by itself... However it looks like the extension doesn't actually add a 'repo_path' key. The primary key as currently defined consists of (cp_repo_id, cp_rev_id, cp_path). cp_repo_id is a constant (within the given repository we're working with), but cp_rev_id will vary. If we're returning filtered results listed by time -- as we are for what you actually type in -- then that's pretty good. But if we're trying to let someone type an arbitrary path, we probably want to bias to the *path prefix* not to *recent revision ids*. Searching based on an index built on (cp_repo_id, cp_path) will give more efficient path lookups, but probably isn't super efficient either because it'll have a huge number of duplicate (for our purposes) rows listing the same paths over and over. We probably don't want the DB to go through all 600k+ matching rows building a DISTINCT set (which it might, or might not, be smart enough to optimize out). -- 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
