Brian DeFeyter wrote:
> 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.
That only works after you've wait 2 minutes for the query to complete. I want
something (like EXPLAIN) that is fairly quick and that you can run ahead of time.
>
>
---------------------------------------------------------------------
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
