Limit number of rows from wildcard expansion- DRG-51030

Question

We use CONTEXT iindex in 11g to search on a text DB column, "Name".
This is used in a UI to show autosuggest list of 25 matching names.
When the end user types an 'a' we want to show a list of the first 25 names that contain an 'a'.
We hit the issue of too many matches in the wildcard expansion query:
DRG-51030: wildcard query expansion resulted in too many terms
This is a frequent use case when the user types just 1 character ('a' will easily match over 50K names in our case).
Is there a way to make the wildcard expansion query only return the first 25 rows?
We never show more than 25 names in our UI - so we would like the expansion query to also return max of 25 rows.
Our query is:
SELECT ResEO.DISPLAY_NAME,
ResEO.RESOURCE_ID,
ResEO.EMAIL
FROM RESOURCE_VL ResEO
WHERE CONTAINS (ResEO.DISPLAY_NAME , '%' || :BindName || '%' )>0
Also,
Is there a way to use CTXCAT type of index and achieve this (expansion query limit of 25)?
We are considering switching to CTXCAT index based on documentation that recommends this type of an index for better performance.

Answer 1

Your best bet may be to look up the words directly in the $I token table.
If your index is called NAME_INDEX you could do:
select /* FIRST_ROWS(25) */ token_text from
  (  select token_text
     from dr$name_index$i  
     where token_text like 'A%' )
where rownum < 26;That should be pretty quick.
However, if you really want to do %A% - any word which has an A in it - it's not going to be so good, because this will prevent the index being used on the $I table - so it's going to do a full table scan. In this case you really need to think a bit harder about what you're trying to achieve and why. Does it really make any sense to return 25 names which happen to have an A in them? Why not wait until the user has typed a few more characters - 3 perhaps? Or use my technique for one or two letters, then switch over to yours at three characters (or more).
A couple of notes:
- Officially, accessing the $I table is not supported, in that it could change in some future version, though it's pretty unlikely.
- I trust you're using the SUBSTRING_INDEX option if you're doing double truncated searches - a wild card at the beginning and end. If not, your performance is going to be pretty poor.