On Sun, Feb 29, 2004 at 12:53:46PM +0100, Ivo Köthnig wrote:
Am Samstag, 28. Februar 2004 20:47 schrieb Tomasz Wegrzanowski:
For sorted lists (index) you will need heaps. Sorting for the largest articles is one example. I think MySQL would use heaps (or hash-tables) for such thinks...
No, it wouldn't use heaps. MySQL would use B+tree index.
I think a B+tree is nothing else than a special heap...
If you think "heap" as in "priority queue", then no.
indexes were set up right. As they aren't, it has to go through entire database (including cur_text) to find largest articles, project it so it contains only sizes, then use generalized merge sort to find the largest articles.
Yes, so we should have an index for that. It should be fastet to have an O(logn)-Operation more for each edit instead of a O(n*logn)-Search each time a user want the largest articles... (n = Number of articles)
Don't think O(). n on Wikipedia is known. By separating cur_text from the rest of cur we can make all searches order of magnitude faster - without changing O().