https://bugzilla.wikimedia.org/show_bug.cgi?id=17993
--- Comment #11 from Roan Kattouw <roan.katt...@gmail.com> 2011-06-14 18:32:59 UTC --- (In reply to comment #10) > Isn't there even an SQL command to return just the length of the matched set > instead of the items themselves? Yes. It's COUNT(*) > Of course Roans explanation is good, but this > is only the price for one query. It's not the same price. A LIMIT 50 query only inspects 50 rows (or maybe a bit more if there's a WHERE clause that can't be done with an index), whereas a COUNT(*) query will inspect all rows in the entire result set in order to count them. That could be a million rows in extreme cases (e.g. counting the number of category members of Living_people on enwiki, I think that's like 750k members). It should be obvious that a query examining 100 rows is much, much faster than a query that inspects almost a million. > If my aim was to count the set, I would have > to make all the continue-queries, which means the same searching through the > table as it would have been for one query. Of course, this might be an > argument > to repeal any api limits, but the real advantage is the save of bandwidth and > PHP-requests. > Yes, it means the entire result set will be scanned eventually. But there's an advantage to not doing that all at once. Count queries of a high magnitude can easily take a minute, and at some point things start timing out (PHP max exec time limit, timeouts on the client side, timeouts in intermediate caching proxies) So we could return a count, but we'd keep paging in. -- 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
