I do not believe that is a supported feature of SQL Server full text searching. That would require a wildcard resolution to words and then a thesaurus lookup of each matching word to gather the thesaurus terms.
This basically maps to a pretty complex query: some one of a group of prefixed words is very near to some one of another group of prefixed words which all then go through a thesaurus lookup to provide even more words. Based on previous experience, that is just not supported.
(I see online that you have asked this elsewhere in the last few months, but without any answers, so I hope that this helps.)
I believe that you can create something useful for your query, but it probably requires externalizing the thesaurus entries by doing something like the following:
DECLARE @FirstGroup TABLE (AGroup NVARCHAR(50));
INSERT INTO @FirstGroup VALUES ('hdd');
INSERT INTO @FirstGroup VALUES ('hard disk');
INSERT INTO @FirstGroup VALUES ('hard disc');
INSERT INTO @FirstGroup VALUES ('harddisk');
DECLARE @SecondGroup TABLE (BGroup NVARCHAR(50));
INSERT INTO @SecondGroup VALUES ('sata');
INSERT INTO @SecondGroup VALUES ('msata');
INSERT INTO @SecondGroup VALUES ('esatap');
DECLARE @SearchString NVARCHAR(2000);
SET @SearchString = ''
SELECT @SearchString = @SearchString + '("'+AGroup+'"~"'+BGroup+'") OR '
FROM @FirstGroup CROSS JOIN @SecondGroup
SELECT @SearchString = LEFT(@SearchString, LEN(@SearchString) - 3);
SELECT * FROM dbo.TBL_NAME
WHERE contains(field_name,@SearchString);
So if you load the tables with the candidate thesaurus entries and make the OR connections in the code, it should work just fine.
You did not mention which version of SQL Server you are running, but if you are using SQL Server 2012, you might want to use the newer and more powerful syntax. However, this article also has hints about the legacy NEAR context.
http://technet.microsoft.com/en-us/library/ms142568(v=sql.110).aspx
Did you try to replace the insert..union statements with separate insert statements?
For example:
insert into @containsTable select [key],[rank] from ContainsTable(File2010,Content,@keywords)
insert into @containsTable select [key],[rank] from ContainsTable(File2000,Content,@keywords)
insert into @containsTable select [key],[rank] from ContainsTable(File1990,Content,@keywords)
insert into @containsTable select [key],[rank] from ContainsTable(File1980,Content,@keywords)
insert into @containsTable select [key],[rank] from ContainsTable(File1970,Content,@keywords)
It could be as simple as the increased processing cost of union plus the increased memory usage from having 5 processes open at the same time to use them on that insert, slowing down your UDF.
(Also, since you're querying from - supposedly - unrelated data tables, the 'distinct' part of union should be unnecessary.)
Best Answer
No is the short answer, and you don't really need this. Full-text indexes are inverted indexes so they store the split words by the unique doc_id that you have to specify when you create the full-text index. This must be a "unique, single-key, non-nullable column" ideally an integer. What is essentially a foreign key does not figure and there is no easy way to partition them on that basis.
You could spoof something like this it with a table per company and full-text index per table. You would need some kind of code logic sat in front to determine which table to insert to / fetch from. This would be a considerable headache to manage at is almost certainly not worth it.
If you had some serious volume ( eg more like 23 billion records ) then you could look at a sharding solution, eg something like an Azure VM per company with an app sat in front of them to determine which machine to connect to. But clearly you don't need that either.
There were also a number of improvements in SQL 2008 to full-text which is now more integrated into the database engine. One scenario, where you specify a WHERE clause against a normal column and use the full-text functions, is referred to as a 'Mixed Query' and discussed here. This is still a great article even though the information is for SQL 2008.
If you're generally concerned about performance and plans, why not spin up some test data, introduce some skew and try it out. I knocked up this script with ~2 million rows in a few minutes: