Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Pastimes : Silicon Investor, under the hood -- Ignore unavailable to you. Want to Upgrade?

To: InternetPlay who wrote (4)	12/12/2004 8:48:10 PM
From: mas_	Read Replies (1) \| Respond to of 81

you might want to physically load the data together based on the subjectid If there is a clustered index on subjectid that would be done automatically and that usually happens with a Sybase/SqlServer primary key IIRC. I suggest a primary key of subjectid, creation date perhaps also another index on authorid, creation_date. I don't see much point in including the message field in the index as that would make it too big and inefficient, like a table scan, and the first letter of the message is usually meaningless like the first letter of a name ;-).

To: InternetPlay who wrote (4)	12/12/2004 9:07:41 PM
From: SI Bob	Respond to of 81

make sure the index is built on subjectid first, and then the message field, I bet you'll see a big performance gain when you run the query in your earlier post, provided that the number of records for the given subjectid is relatively small. I prefer to keep most indexes as single-field ones with a few exceptions like subjectid, message_order. Not all searches (relatively few of them, actually) will care about the subjectid except for including it in the returned recordset. Including it just for purposes of making it a covered query wouldn't do any good since I wouldn't be indexing the message text field. I assume you mean the messageid field rather than the message field. I doubt SQL Server would let me index a full-text field, but even if it did, it wouldn't do any good. Indexing a field that often contains thousands of characters wouldn't do any good when you're looking for a string that could be several thousand characters deep into the message. When it comes to message-searching, you either have to use MSSearch (so you can use contains() and other functions) or build your own. I haven't decided to roll my own yet because we're very far from really needing it and might never.