Use the stored procedure search interface when your application needs a subset of the text search result, but in a high performance way. Do not use the stored procedure if you require all the results, or you need to index a large number of documents. The main reason being that as parts of the user table are copied into memory, a lot of real memory needs to be available.
You can use the stored procedure to first request results from 0 to 20, then 21 to 40, and so on, in a similar way to cursor navigation. Combining this cursor capability with the use of a cache (calculated during indexing), searching is extremely fast, especially as no join is necessary.
If you are going to use the stored procedure, ensure that you consider the following options:
The following is an example of a stored procedure search:
db2 "call db2ext.textSearch('\"book\"','DB2EXT','COMMENT',0,2,1,1,?,?)"
The first parameter is the search term. The syntax is exactly the same as in the SQL functions. Then specify the index name and index schema. If you have not masked the name, it is translated to uppercase. The following two numbers give you the probability of getting the result in slices. The next two integer values specify if score and hit information are requested. The last two values are output values.
See Chapter 16, Stored procedure search function for further details on the parameters.
Note |
---|
If you request larger result sets, you need a user tablespace. If there is none available, create a tablespace. The following example creates a tablespace on a UNIX platform: db2 "create user temporary tablespace tempts managed by system using ('/work/tempts.ts')" In a distributed DB2 environment, you must explicitly specify a tablespace for administration tables on a single node for the stored procedure and explicitly call on this node. |