https://bugzilla.wikimedia.org/show_bug.cgi?id=32944
--- Comment #2 from [email protected] 2011-12-10 21:20:15 UTC --- I agree the "sort" parameter would make no sense. I'm not sure that "limit" would make no sense. I have considered using "limit" on counts when there are a lot of counts, to improve performance. For example, a query could be used to detect any count over 100, and then that information can be used to produce a links to several pages of further results, using queries like this: {{#ask: [[Category:Some category]] | limit=101 | offset=0 | format=count}} {{#ask: [[Category:Some category]] | limit=101 | offset=200 | format=count}} {{#ask: [[Category:Some category]] | limit=101 | offset=300 | format=count}} {{#ask: [[Category:Some category]] | limit=101 | offset=400 | format=count}} Of course, I'm assuming that putting a limit on counts would improve performance, since I don't know how counts are produced internally (they may be cached, or produced by some fast method). I'm also guessing that these operations one at a time in sequence, only when requested would have better performance than doing them all at once on every page load. When offset doesn't work, I suspect counts will not be accurate when the number exceeds $smwgQMaxLimit (I haven't tried it). I also suspect an offset ability would allow $smwgQMaxLimit to be set higher than the default 10000, with conscientious use of count, offset, and limit to ensure adequate performance. What do you think? -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
