Steve Rapaport wrote:
>
> Someone correctly pointed out today that it's not Mysql's job
> to be Google, and I agree. But it seems to me that it would be
> fair for mysql to be able to handle searches in under 1 second
> for databases 1 millionth the size of Google. All I want here
> is a decent flexible phone book lookup, not a search engine.
That may be what you want. But I want a search engine. For my database. I want
to be able to do search of the million records of inventory in our database and
find the items with certain keywords, that are currently available for sale, in
the venue the user is shopping in and within the price range the user specifies.
This is a combination of database and fulltext search that I think is exactly in
MySQL's marketplace.
And the current situation where a user fulltext query can take between 1 ms and
100 secs with no easy way for the application to tell ahead of time is really
unacceptable.
So I think several things need to be done:
1) full text search needs to be faster (they are working on it).
2) There needs to be some way (ala explain) of figuring out roughly how long a
particular full text search will take. If I coudl do
EXPLAIN SELECT * FROM inventory WHERE MATCH ($userQuery) AGAINST (title,
description)
and get something useful for predicting search time. Then I could at least say
something to the user like:
That query matches too many records. Please pick a more specific query.
Rather than hosing the whole database for 3 or 4 common words.
3) Find ways to use replication and memory to speed up full-text queries. See my
previous mail about heap tables for a possible example.
---------------------------------------------------------------------
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
