On Wed, 2002-02-13 at 16:39, Mike Wexler wrote: > > > Brian DeFeyter wrote: > > I sorta like that idea. I don't know exactly what you can and can't do > > as far as indexing inside of HEAP tables.. but the index size would > > likely differ from the written index. Then you can expand the idea and > > use the X/(num slices) on (num slices) boxes technique.. sending the > > query to each, and compiling all of the results. > > > > Your comment about only having a few common words that are searched > > makes me wonder if a reverse-stopword function would be valuable (ie: > > only index words in a list you generate) Probably could be done other > > ways though too with what's available. Maybe a psuedo-bitmap index > > inside a mysql table? > > I don't think that would be appropriate. My example, is our site (tias.com) has > lots of antiques and collectibles. One popular categories is jewelry. If > somebody does a search for "gold jewelry" and the search engine interprets this > as anything that mentions gold or jewelry. It is going to match a lot of items. > It would be nice if we could use explain or something like it to get a rough > estimate of how many results a query would generate, and if it was really bad, > we could tell the user to be more specific.
The FOUND_ROWS() function in mysql-4.0.0+ might help you out in this case. --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php