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: Joe NYC who wrote (16)	12/13/2004 12:48:14 PM
From: mas_	Read Replies (1) \| Respond to of 81

75 Mb of data read from disc is not a big deal, can be done in seconds, it's when it is Gbs to Tbs it gets leary ;-). The cpu search string time would probably be of a similar time. In fact I have just done such a query on a similar sized table and it took 15 seconds.

To: Joe NYC who wrote (16)	12/14/2004 5:43:11 PM
From: SI Bob	Respond to of 81

If I were doing that as a way to use LIKE rather than CONTAINS(), I wouldn't need to build out separate search tables for each subject. I'd run LIKE on the results of a subquery that returned all messages where the subjectid were the desired one. As I mention a message or two back, though, searching from a Subject page is very, very fast, though, mostly because it's using a stored proc with only 3 JOINs and only 2 ANDs in the WHERE. Have to use T-SQL for Advanced Search because the number of JOINs and AND's (plus possibly some ORs) is completely unknown until the user fills out the form.