Tag Info

New answers tagged

0

You should really consider upgrading to a more recent version, especially if you want to utilize some of the best parts of Full Text Search. To your question, the short answer is yes. From the documentation for 2005, you have two main features to customize in a thesaurus, Expansion Sets and Replacement Sets: An expansion set contains a group of ...


0

One common work-around for slow OR performance is to separate the parts and UNION ALL them back together: select * from dbo.company p with (nolock) join dbo.alt_company o with (nolock) on p.org_id = o.org_id where CONTAINS (p.description, '"phrase1*" OR "phrase2"') UNION ALL -- note the "ALL", this will prevent a "DISTINCT" select * from ...


0

Took me a little while to see what now seems obvious. I can't seem to replicate your experience with John v. Smith on 2012, but if we check out the default system stopwords... select * from sys.fulltext_system_stopwords WHERE stopword = 'v.' The result is stopword language_id v. 1053 So it seems the stoplist is the problem. Let's try a ...


0

The score can only be accessed with a CONTENT index using a query like this SELECT ID, TEXT,SCORE(1) FROM t WHERE CONTAINS(text, 'my query',1) > 0 ORDER BY SCORE(99) DESC; By Oracle 11 everything you can do with a CTXCAT index you can do more with a CONTENT index. Why not use that? Edit: The op asks if CONTENT indexes must be synced. Yes, this is ...


0

If you are updating by replacing the data, then this has 'zero' downtime. CREATE TABLE new LIKE real; Load the new data into new. The new FT index will be built. `RENAME TABLE real TO old, new TO real; -- fast and atomic; hence zero downtime. DROP TABLE old;


0

A good way to update FT indexes, if they are somewhat big is to. 1. Drop the FT index 2. Update the data 3. Add new FT index. I had major problems updating tables with FT indedxes when they grew big, this solution worked for me. I have now however moved all FT indexing to a Lucene solution.


0

The setup program restarts the target instance when installing full text search. However, there's an easy way to find out: test it! Don't trust what I say: test it in your test environment.


1

Summary: VARCHAR and TEXT are identical for reading, storing, FULLTEXT, and virtually everything else. Some INDEX/SELECT differences are noted below. MariaDB and MySQL are (I'm pretty sure) the same as each other in this area. Some reason for 765? What CHARACTER SET are you using? (Ascii versus utf8 -- there could be differences.) For "small" VARCHARs ...


1

As far as Postgres is concerned, there is no difference in performance. And there is no length modifier for text to begin with, just (optionally) for varchar. Unless you need to enforce a certain length, just use text or varchar. Would index lookup be noticeably faster with char vs varchar when all values are 36 chars To support pattern matching with ...



Top 50 recent answers are included