In the last few days during this series, I got many question about this Wait type. It would be great if you read my original related wait stats query in the first post because I have filtered it out in WHERE clause. However, I still get questions about this being one of the most wait types they encounter. The truth is, this is a background task processing and it really does not matter and it should be filtered out.

There are many new Wait types related to Full Text Search that are introduced in SQL Server 2008.

If you run the following query, you will be able to find them in the list. Currently there is not enough information for all of them available on BOL or any other place. But don’t worry; I will write an in-depth article when I learn more about them.

SELECT *
FROM sys.dm_os_wait_stats
WHERE wait_type LIKE 'FT_%'


The result set will contain following rows.

FT_RESTART_CRAWL
FT_METADATA_MUTEX
FT_IFTSHC_MUTEX
FT_IFTSISM_MUTEX
FT_IFTS_RWLOCK
FT_COMPROWSET_RWLOCK
FT_MASTER_MERGE
FT_IFTS_SCHEDULER_IDLE_WAIT

We have understood so far that there is not much information available. But the problem is when you have this Wait type, what should you do?  The answer is to filter them out for the moment (i.e, do not pay attention on them) and focus on other pressing issues in wait stats or performance tuning.

Here are two of my informal suggestions, which are totally independent from wait stats:

• Turn off the Full Text Search service in your system if you are  not necessarily using it on your server.
• Learn proper Full Text Search methodology. You can get Michael Coles’ book: Pro Full-Text Search in SQL Server 2008.

Now I invite you to speak out your suggestions or any input regarding Full Text-related best practices and wait stats issue. Please leave a comment.

Note: The information presented here is from my experience and there is no way that I claim it to be accurate. I suggest reading Book OnLine for further clarification. All the discussions of Wait Stats in this blog are generic and vary from system to system. It is recommended that you test this on a development server before implementing it to a production server.

Reference: Pinal Dave (http://blog.SQLAuthority.com)