Tag Info

New answers tagged

1

Pattern matching and operators Full text search is not the right tool for pattern matching (and possibly even fuzzy, fault tolerant input). Typically, trigram-similarity search with the % operator is the superior approach here. You need to install the additional module pg_trgm once per database: How do I create an index to speed up an aggregate LIKE query ...


0

Usually FULLTEXT searches need more than a single letter, there is actually a setting that prevents them from being used if less than X number of characters are used. ft_min_word_length: The minimum length of the word to be included in a FULLTEXT index. Note: FULLTEXT indexes must be rebuilt after changing this variable My guess is that you are not ...


0

Catalog and index are separate. What do you see in sys.fulltext_indexes? Did you confirm data there after the index was created? You could check for recent Object:Deleted events in the default trace: DECLARE @path NVARCHAR(260); SELECT @path = REVERSE(SUBSTRING(REVERSE([path]), CHARINDEX(CHAR(92), REVERSE([path])), 260)) + N'log.trc' FROM ...


3

There is already an existing answer posted by Aaron Bertrand for SQL Server Express 2012. First install SQL Server 2014 Express with Advanced Services as you did. Then read Aaron's instructions at: http://stackoverflow.com/questions/10407337/express-with-advanced-services-cant-create-full-text-index The short version is that the user interface does not ...


1

I am assuming that you want the Oracle optimizer to pick tableb as the driver table and for each row in tableb, have it run an index scan for tablea (Since tablea has 3GB of data). Your indexes start with col4, so I am guessing you are hoping that one of them will be used by the optimizer. One thing to point out is that in your WHERE clause you have both: ...


1

From the documentation: Full table scans are cheaper than index range scans when accessing a large fraction of the blocks in a table. Full table scans can use larger I/O calls, and making fewer large I/O calls is cheaper than making many smaller calls I suggest reading that entire page and then asking a more specific question if the optimizer is ...


1

This may be about the selectivity of your predicates. If a query uses an index it suffers the overhead of reading from disk the pages which constitute the index itself. If instead it performs a table scan it has the overhead of retrieving data it will ignore. The relative cost of these two options will depend on the selectivity of your index, how the ...


0

I finnaly found something : Reboot the server ! I absolutely have no idea why. Thanks @wBob for your help.


0

You might try scripting it out to see if you get a different behaviour. This simple example runs in under a minute on my local SQL 2005 instance: USE master GO SET NOCOUNT ON GO IF EXISTS ( SELECT * FROM sys.databases WHERE name = 'fullTextDemo3' ) BEGIN ALTER DATABASE fullTextDemo3 SET SINGLE_USER WITH ROLLBACK IMMEDIATE DROP DATABASE ...



Top 50 recent answers are included