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
===========================