This is actually part of a much larger complex query.
According to the query plan the sort on this statement dominates the cost of the larger query.
And by materializing
Just for giggles again, could you try this query:
select
[sID],
ROW_NUMBER() over (partition by [sID] order by [wordPos]) [rn],
[wordPos], [FTSindex].[wordID]
from [FTSindex]
join (
values (428), (2112)
) w (wordID) on w.wordID = [FTSindex].wordID
order by [sID], [rn]
Sometimes, throwing more hardware at the problem is the correct answer; though I agree that this should be a last resort and not a first. Whether this particular problem requires more CPU, more memory, or more spindles is dependent on many factors, including your present hardware.
Your result set of 1.6 million rows, each 4 integers, should sort quickly on any reasonable amount of current hardware. Since delays are occurring it seems likely that too much processing is occurring on the base set of 900 million rows, and the challenge is to identify why. Can you attach more details about the query plan?