Thanks for the quick response.
Ok, well I decided to switch the database back to test it, and it is slow as hell again. This time I did:
for a in $(ls *frm | cut -f1 -d. ); do echo "use mythconverg; ALTER TABLE $a TYPE=MYISAM;"|mysql ; done
From your symptoms and without looking at the code, my first thought was some kind of transaction wrapping in the myth delete function so that the metadata delete and disk delete would both be sure to happen. However, in retrospect I think that's a bit advanced for mysql.
So that suggests that the next most likely place to look is the recorded markup table. If you have an mpeg2 recording then you have a huge bunch of rows stored in this table which have to be deleted. Can you try just changing this single table and re-benching to see what happens?
If this is the case then you can at least grep the code and find the delete function and see if it's doing the delete in the obvious way, rather than one row at a time. If there is nothing to optimise here then I guess we could look at whether the table is under/over indexed. Failing that I think switching that table to innodb sounds like the way ahead...
Curious to hear if you can track it down further to a single table
Ed W
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
