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().