[fastforward]

That query probably will use a fair bit memory as it's joining to the post table. This was added to eliminate the need for a unique constraint on the msgid column in the post table. The unique key had a potential to cause problems with vB upgrades and uninstalling the hack etc.

You can remove the DISTINCT clause from the query. That is causing a sort when it's not really required as we're joing on msgid which should be unique in both tables. See if that stops it creating a temp table.

Also, make sure you have indexes on the msgid column in the post table and the msgid column in the usenet_article table.

The usenet_article msgid should be the PRIMARY_KEY or UNIQUE.

The post msgid should be a non-unique index.

Has the performance always been the same?
If that still doesn't work, you might try removing the LOW_PRIORITY from the statement. It shouldn't make any difference, but you never know.