> -Original Message-
> From: Ananda Kumar [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2008 10:48 AM
> To: [EMAIL PROTECTED]
> Cc: mos; mysql@lists.mysql.com
> Subject: Re: Fulltext index -first query slow, subsequent queries fast
>
> Hi
>
> Is sphi
Hi
Is sphinxsearch avialable only on for windows
regards
anandkl
On 6/13/08, Rory McKinley <[EMAIL PROTECTED]> wrote:
>
> mos wrote:
>
>
>> Why not switch to Sphinx full text search for MySQL? It is faster and can
>> handle more data than MySQL's built in fulltext search.
>> http://www.sphinxsea
mos wrote:
Why not switch to Sphinx full text search for MySQL? It is faster and
can handle more data than MySQL's built in fulltext search.
http://www.sphinxsearch.com/
Mike
I have read about sphinx and the good performance boost it provides -
unfortunately there is a lot of legacy code
At 02:20 PM 6/12/2008, you wrote:
Hi List
I have a table with a fulltext index across five fields, with about 2.2
million records and a data size of about 5.6 GB (index another 3.5 GB).
When I test a query that uses fulltext matching, the first run takes about
15-16 seconds to complete. The s
>From: Rory McKinley [mailto:[EMAIL PROTECTED]
>Sent: Thursday, June 12, 2008 4:57 PM
>To: Jerry Schwartz; mysql
>Subject: Re: Fulltext index -first query slow, subsequent queries fast
>
>Jerry Schwartz wrote:
>> File system, or disk caching, uses some kind of algorithm to
Jerry Schwartz wrote:
File system, or disk caching, uses some kind of algorithm to hold chunks of
files in system RAM. That way a program can get to it more quickly than if
it had to go out to the disk. The algorithms vary, depending upon the smarts
of the program and the smarts of the file syste
>-Original Message-
>From: Rory McKinley [mailto:[EMAIL PROTECTED]
>Sent: Thursday, June 12, 2008 3:20 PM
>To: mysql
>Subject: Fulltext index -first query slow, subsequent queries fast
>
>Hi List
>
>I have a table with a fulltext index across five fields, with about 2.2
>million records and
Justin wrote:
I'm wanting to add a new field to my table that I will both be
grouping by, searching with full text hits and plain likes..
I know I'll need a FULL TEXT index, but will that full text index
also index like a normal index will? or should I also add an index
too..
You'll need to ad
Horst Azeglio wrote:
I'm trying to do a MySQL Query but it doesn't work. MySQL version: 4.0.26
When I put only one argument in MATCH, it shows no error but doesn't return
anything
[quote]
SELECT * FROM item WHERE MATCH (nom) against ('Huile');[/quote]
or
[quote]SELECT * FROM item WHERE MATCH (n
All,
- Original Message -
From: "mos" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.myodbc
Sent: Sunday, January 30, 2005 6:29 AM
Subject: Re: FULLTEXT index on InnoDB tables (looking for a workaround)
At 02:32 PM 1/28/2005, you wrote:
And, of course, another opti
At 02:32 PM 1/28/2005, you wrote:
And, of course, another option is to contact Heikki and coax him into
hiring somebody to add FULLTEXT to InnoDB tables.
And bring lots of cash with you. :-) I've pestered Heikki a couple of years
ago and he's willing to do it only if there is someone willing to f
symbulos partners wrote:
Thanks for the extremely useful answer.
Some comments, questions here below.
On Friday 28 Jan 2005 16:38, you wrote:
No, only the BLOB/TEXT columns need to be moved to MyISAM.
Yes, I thought of doing so. The drawback is that you de-normalise the
database. Is that correct?
symbulos partners wrote:
Is there any other workaround? The reason because we are using InnoDB is
because there s full support
- for foreign keys,
- for joint queries
- for rollback on commit
Does anybody know any other way of indexing the table in a way, which would
allow full text search?
Thanks for the extremely useful answer.
Some comments, questions here below.
On Friday 28 Jan 2005 16:38, you wrote:
> No, only the BLOB/TEXT columns need to be moved to MyISAM.
Yes, I thought of doing so. The drawback is that you de-normalise the
database. Is that correct?
There are 2 alterna
Thanks for the extremely useful answer.
Some comments, questions here below.
On Friday 28 Jan 2005 16:38, you wrote:
> No, only the BLOB/TEXT columns need to be moved to MyISAM.
Yes, I thought of doing so. The drawback is that you de-normalise the
database. Is that correct?
There are 2 alterna
> > > As you have noticed - you cannot.
> > >
> > > So, all you can do is creating a MyISAM table and copying
> > > the column contents.
> >
> > Are you suggesting to have a full copy of the table in MyISAM format?
>
> No, only the BLOB/TEXT columns need to be moved to MyISAM.
>
> >
> > Is there a
symbulos partners <[EMAIL PROTECTED]> wrote on 01/28/2005 11:14:00 AM:
> On Friday 28 Jan 2005 15:41, you wrote:
> > As you have noticed - you cannot.
> >
> > So, all you can do is creating a MyISAM table and copying
> > the column contents.
>
> Are you suggesting to have a full copy of the table
On Friday 28 Jan 2005 15:41, you wrote:
> As you have noticed - you cannot.
>
> So, all you can do is creating a MyISAM table and copying
> the column contents.
Are you suggesting to have a full copy of the table in MyISAM format?
Is there any other workaround? The reason because we are using Inn
Hello,
> I would need to index FULLTEXT two columns in a InnoDB table. How do you
solve
> the problem?
As you have noticed - you cannot.
So, all you can do is creating a MyISAM table and copying
the column contents.
With regards,
Martijn Tonies
Database Workbench - developer tool for InterBase
Hi Joyce,
"needs" is a stopword, that's why it's not indexed or found. You can
use your own ft_stopword_file to define the list without "needs." The
default, built-in stopword list is defined in, I think, the
myisam/ft_static.c file of the source distribution, for reference.
Hope that helps.
I find doing this helps to reinitialize the indexes
ALTER TABLE shotlist TYPE=MyISAM;
REPAIR TABLE shotlist QUICK;
> I am trying to add a second fulltext index to an already existing table
> (named "articles").
>
> The first index is for field(column name) "text" of type "longtext"
>
> I want to
Hi Matt, thanks for the help.
Meanwhile the index has been built, and I assume it's a problem of
terminal sessions:
At first I tried it with a remote mysql client issuing the ALTER TABLE
command. This session was closed after some inactivity.
Then I logged in to the database host and retried -
Hi sascha,
How's the space on your datadir partition (or wherever this table is)?
I believe MySQL creates the temp tables during ALTER in the DB
directory, not the tmpdir.
If the space there is OK, have you checked the error log for anything
related?
Matt
- Original Message -
From: "s
At 08:51 AM 2/2/2004, you wrote:
"Hassan Shaikh" <[EMAIL PROTECTED]> wrote:
> Is there any plan to introduce FULLTEXT indices under InnoDB table
> types?
>
Full-text search is in the InnoDB TODO list:
http://innodb.com/todo.html
But it's a long-term goal.
If anyone has the cash to sponsor t
"Hassan Shaikh" <[EMAIL PROTECTED]> wrote:
> Is there any plan to introduce FULLTEXT indices under InnoDB table
> types?
>
Full-text search is in the InnoDB TODO list:
http://innodb.com/todo.html
But it's a long-term goal.
--
For technical support contracts, goto https://order.mysql.
Hi Peter,
I don't know what your multiple languages are, but remember that
full-text indexing doesn't currently work with multi-byte character
sets.
Anyway, the "built in" stopword list is in the myisam/ft_static.c file
of the source code. This is mentioned in the manual for SHOW VARIABLES:
http:
Sergei Golubchik wrote:
> On Sep 06, Andreas Schwarz wrote:
>> Egor Egorov wrote:
>> > Andreas Schwarz <[EMAIL PROTECTED]> wrote:
>> >>
>> >> is it possible to use Fulltext indexes on unicode (UTF-8 or UCS-2)
>> >> fields in 4.1?
>> >>
>> >
>> > Nope. Fulltext search doesn't work with multi-byte
Hi!
On Sep 06, Andreas Schwarz wrote:
> Egor Egorov wrote:
> > Andreas Schwarz <[EMAIL PROTECTED]> wrote:
> >>
> >> is it possible to use Fulltext indexes on unicode (UTF-8 or UCS-2)
> >> fields in 4.1?
> >>
> >
> > Nope. Fulltext search doesn't work with multi-byte character sets.
>
> Will th
At 11:25 + 9/6/03, Andreas Schwarz wrote:
Egor Egorov wrote:
Andreas Schwarz <[EMAIL PROTECTED]> wrote:
is it possible to use Fulltext indexes on unicode (UTF-8 or UCS-2)
fields in 4.1?
Nope. Fulltext search doesn't work with multi-byte character sets.
That's correct. It's documented at:
Egor Egorov wrote:
> Andreas Schwarz <[EMAIL PROTECTED]> wrote:
>>
>> is it possible to use Fulltext indexes on unicode (UTF-8 or UCS-2)
>> fields in 4.1?
>>
>
> Nope. Fulltext search doesn't work with multi-byte character sets.
Will this be fixed in future versions? Otherwise I would have to
d
Andreas Schwarz <[EMAIL PROTECTED]> wrote:
>
> is it possible to use Fulltext indexes on unicode (UTF-8 or UCS-2)
> fields in 4.1?
>
Nope. Fulltext search doesn't work with multi-byte character sets.
--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is s
On Thu, Feb 27, 2003 at 09:27:41AM -0500, Brent Baisley wrote:
> Maybe you should rethink your whole database structure. In your
> simplified example, you really only have two pieces of data, the text
> and a qualifier (a, b, c, d, e, ...). So instead of separating your
> "text" into different c
Maybe you should rethink your whole database structure. In your
simplified example, you really only have two pieces of data, the text
and a qualifier (a, b, c, d, e, ...). So instead of separating your
"text" into different columns, keep all your text in one column and add
another column that a
Thank you Paul and Diana,
I the 6 hours that passed before my message appeared on the list I rechecked
the excellent MySQL documentation and found the answer as indicated by both
of you. I just missed to look for the answer under restrictions... my fault.
Best/h
On 1/31/03 11:12 AM, "Diana Soar
Hi,
"The MATCH() column list must exactly match the column list in some
FULLTEXT index definition for the table, unless this MATCH() is IN
BOOLEAN MODE."
from:
http://www.mysql.com/doc/en/Fulltext_Restrictions.html
On Thu, 2003-01-30 at 21:40, R. Hannes Niedner wrote:
> If I create a FULLTEXT
At 13:40 -0800 1/30/03, R. Hannes Niedner wrote:
If I create a FULLTEXT index for 2 or more columns in a table will I be able
to use it for a MATCH only against a single column (of the above) or do I
have to create additional FULLTEXT indices for each of these columns?
The latter. When you use
Thanks Paul - it worked perfectly. And for anyone else listening, modifying
the table did not adversely affect the data (although I did back up just in
case). --Aaron
On 11/1/02 7:34 PM, "Paul DuBois" <[EMAIL PROTECTED]> wrote:
> At 15:25 -0600 11/1/02, Aaron Merrick wrote:
>> Ladies & Gentleme
At 15:25 -0600 11/1/02, Aaron Merrick wrote:
Ladies & Gentlemen,
The manual says "FULLTEXT indexes are used with MyISAM tables and can be
created from VARCHAR and TEXT columns at CREATE TABLE time or added later
with ALTER TABLE or CREATE INDEX."
Believe the manual.
I get the following error
I'm not sure about not being able to put FULLTEXT on blobs, but it would
make sense that it only works on specifically text fields. Here is the
syntax to change the column type (this may affect the data stored so you
might want to dump the data and reimport after you have changed the column
type)
Hi!
On Aug 12, Ryan Barber wrote:
> Is anyone else still having problems with fulltext indexed tables using
> 4.0.2? Ours crashed over the weekend during an update, corrupting the
> table. The server was left running, which is an improvement over the
> behavior of 4.0.1, where the whole serve
Hi!
On Apr 15, Nicholas Murphy wrote:
>
> The query
>
> select * from tablename where match(column_name)
> against('three');
>
> fails to match any record.
>
> Ten to twelve records in the table are know to have
> the distinct word "three" in them in the indexed column.
>
> Question:
>
>
41 matches
Mail list logo
