Hi,

many thanks for your suggestions.

Very slow "copy to tmp_table" seems to be a known MySQL issue. See: http://forums.mysql.com/read.php?21,82045,82045#msg-82045 MySQL does seem to have problems with (fulltext) index creation

I found a solution (or better: a workaround) at: http://peter-zaitsev.livejournal.com/11772.html :

quot from http://peter-zaitsev.livejournal.com/11772.html: ... Create table of the same structure without keys, load data into it to get correct .MYD, Create table with all keys defined and copy over .frm and .MYI files from it, followed by FLUSH TABLES. Now you can use REPAIR TABLE to rebuild all keys by sort, including UNIQUE keys ...

I did exactly that, and it worked !!

Issuing REPAIR LOCAL TABLE <xx>wiki.text<xxx> QUICK; after creating-renaming (empty) .frm and .myi files

gave following results:

frwiki: frwiki.textns0 | repair | warning | Number of rows changed from 0 to 794523 frwiki.textns0 | repair | status | OK 2 rows in set (31 min 3.00 sec)

dewiki: dewiki.textns0 | repair | warning | Number of rows changed from 0 to 1050514 dewiki.textns0 | repair | status | OK 2 rows in set (45 min 16.31 sec)

enwiki: enwiki.textns0 | repair | warning | Number of rows changed from 0 to 3940175 enwiki.textns0 | repair | status | OK 2 rows in set (2 hours 27 min 2.13 sec)

(Number of rows differs (is smaller) from that of full dumps as only pages of namespace=0 where processed. For my project I need only to analyse pages with ns=0)

Thus, it seems that -to this point- a small computer is enough to come to convenient indexing performance. (My development server is only a 1,7 Ghz Pentium M, 512 RAM)

@Simetrical:

Make sure there's more than enough room in your temp folder

There was plenty of room in my temp folder. So, that does not seem to be the problem.

Alex Hoelzel, http://www.meshine.info

Alexander Hölzel CEO EUTROPA AG

=========================== EUTROPA Aktiengesellschaft Oelmüllerstrasse 9, D-82166 Gräfelfing, Tel 089 87130900, Fax 089 87130902 ===========================